--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-29 06:51 ---
Hmm, rebuild and works for me.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from patchapp at dberlin dot org 2007-05-29 06:45 ---
Subject: Bug number PR31610
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/msg01953.html
--
http://gcc.gnu.org/bugzilla/sh
x.f90: In function 'MAIN__':
x.f90:2: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:3693
for:
real(kind(0d0)), parameter :: r(1) = &
transfer(transfer(sqrt(2d0), (/ .true. /) ), (/ 0d0 /), 1)
print *,r
end
--
Summary: ICE with transfer in gfc_c
--- Comment #4 from brooks at gcc dot gnu dot org 2007-05-29 05:59 ---
I misunderstood something slightly in that last comment; MERGE is elemental, so
the conforming I mentioned doesn't matter. Also, my guess that fixing the
transfer("A", "x", 20) problem would fix the whole thing prove
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-29 05:38 ---
I posted a patch for this:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01949.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 04:52 ---
(In reply to comment #2)
> PR31738 is another "missed vectorization in Fortran", though I don't think
> it's
> really that related to this one.
The vectorizer issue just exposes the real issue and maybe why GCC is
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-29 04:43 ---
(In reply to comment #3)
> (2) add a dce pass after copyprop3?
This is already done now after:
2007-05-24 Zdenek Dvorak <[EMAIL PROTECTED]>
* passes.c (init_optimization_passes): Add dceloop after
--- Comment #2 from jb at gcc dot gnu dot org 2007-05-29 04:30 ---
PR31738 is another "missed vectorization in Fortran", though I don't think it's
really that related to this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
--- Comment #10 from rob1weld at aol dot com 2007-05-29 04:25 ---
Thank you Benjamin.
The next few days I am working to get 4.3.0 to compile on target Cygwin but I
did update my 4.2.1 SVN and will check this out soon.
I'll probably try to hack something so I don't have to run make for
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 04:22 ---
(In reply to comment #4)
> I got the reply "Zarro Boogs found." when I searched for:
You are searching the summary, try the comment section instead.
You get three bugs:
PR 32134
PR 32024
PR 31039
The middle one if
--- Comment #8 from rob1weld at aol dot com 2007-05-29 04:15 ---
I did just run Cygwin's setup.exe and tried a few sites - even kernel.org .
You can't get an update that way. It will either be by SVN/CVS or apply the
patches listed in the links above to your /cygwin directory.
--
h
--- Comment #8 from rob1weld at aol dot com 2007-05-29 03:57 ---
For target i686-pc-linux-gnu it breaks at:
/root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:557: internal compiler
error: in fold_checksum
--- Comment #4 from rob1weld at aol dot com 2007-05-29 03:52 ---
I got the reply "Zarro Boogs found." when I searched for:
ungetc
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=ungetc&known_to_fail_type=allwordssubstr&known_to_wor
--- Comment #17 from rob1weld at aol dot com 2007-05-29 00:28 ---
# cat /root/downloads/gcc-4_3-trunk/LAST_UPDATED
Mon May 28 08:39:31 UTC 2007 (revision 125125M)
Results for 4.3.0 20070528 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-29 00:25 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 00:25 ---
Subject: Bug 31339
Author: pinskia
Date: Tue May 29 00:25:25 2007
New Revision: 125156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125156
Log:
2007-05-28 Andrew Pinski <[EMAIL PROTECTED]>
PR c/
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-29 00:10 ---
The bug is in maybe_fold_offset_to_array_ref.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 00:08 ---
(In reply to comment #2)
> Do you have some sort of dupe check script running or is it just your magic
> powers?
I just searched for __sgetc_r. Nothing special for finding the dup.
--
http://gcc.gnu.org/bugzi
--- Comment #2 from rob1weld at aol dot com 2007-05-29 00:06 ---
Wow Andrew, you were sure on top of that fast...
I _did_ search for various words to attempt to find a similar complaint before
posting. I found none.
I agree that this bug report is a dupe of 31039 .
Do you have some so
Hi,
-O2 Warray-bounds:
=== Cut ===
struct PhaseEntryType
{
char raw_field[50 + 1];
};
int
ParsePhase (char in_cols[15][250], struct PhaseEntryType *P)
{
__builtin_strncpy (P->raw_field, in_cols[2], 50);
}
~
=== Cut ===
triggered by
__builtin_strncpy ((char *) &P->raw_field, (const char
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-29 00:00 ---
This was a newlib bug which was fixed already so closing as such.
You need to update your cygwin libc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|Latest CVS-stage 2-Cannot |[4.3 Regression
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-28 23:57 ---
*** Bug 32134 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 23:57 ---
*** This bug has been marked as a duplicate of 31039 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
,rtlflag,runtime,tree
Thread model: single
gcc version 4.3.0 20070528 (experimental)
Using minimal configure parameters _or_ trying "--disable-initfini-array
--disable-__cxa_atexit" was to no avail. I did search gcc-patches and bugzilla.
The intl/configure script for 4.3.0 is the same as f
--- Comment #76 from pinskia at gcc dot gnu dot org 2007-05-28 22:47
---
*** Bug 32133 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 22:47 ---
You obviously did not read the bugs.html page which lists this as a nonbug:
http://gcc.gnu.org/bugs.html#nonbugs_c
Increment/decrement operator (++/--) not working as expected - a problem with
many variations.
--- Comment #1 from mckelvey at maskull dot com 2007-05-28 22:45 ---
I refetched from svn and rebuilt and it works OK now.
--
mckelvey at maskull dot com changed:
What|Removed |Added
-
I noticed a change in the implementation of the post-increment (i++) operator
in gcc 4.0.1 (Apple build 5367).
The behaviour can be seen with the following code:
---
i += i++;
---
In older versions (< 4) of g++ the 'original' variable is returned by ++,
meaning that the statement given has the ef
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-28 22:07 ---
Subject: Bug 32124
Author: burnus
Date: Mon May 28 22:07:23 2007
New Revision: 125148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125148
Log:
2007-05-28 Tobias Burnus <[EMAIL PROTECTED]>
PR fortr
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-28 21:53 ---
I am no longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-28 21:48 ---
The warning is correct you need to check if str had an error after reading the
integer. This is not a GCC bug.
The IR looks like:
:
__comp_ctor (&str, s, 8);
this.104 = (struct ios_base *) &str.D.25711;
__s
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 21:24 ---
(In reply to comment #0)
> Just a bug report to remind me to add support for @synchronized for 4.2.
4.3 ... (maybe once I finish pointer plus I can get back to fixing libobjc
issues).
--
http://gcc.gnu.org/bugzi
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-28 21:22
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-05-28 21:21
---
No longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-28 21:07
---
I am no longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from brooks at gcc dot gnu dot org 2007-05-28 21:09 ---
Paul, I don't think that's solving the right problem. The code is legal; the
inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which
conforms with a CHARACTER scalar of len=20.
In reducing this, I
--- Comment #9 from brooks at gcc dot gnu dot org 2007-05-28 20:57 ---
Fixed, as per above commits.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 20:56 ---
This is an aliasing issue. The reason why we don't optimize this is because we
think a/b and escape except in Fortran that is not the case.
I think there is another bug about this case somewhere too.
--
pinskia
--- Comment #8 from brooks at gcc dot gnu dot org 2007-05-28 20:54 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:54:49 2007
New Revision: 125142
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125142
Log:
PR fortran/31972
* transfer_hollerith_1.f90: New test.
Added:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:54
---
Created an attachment (id=13624)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13624&action=view)
Patch for this issue
This patch builds on top of Lee Millward's patch to trans-intrinsic:
http://gcc.gnu.org
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-28 20:53 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:53:09 2007
New Revision: 125141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125141
Log:
PR 31972/fortran
* target-memory.c (gfc_target_expr_size): Add
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:48
---
The following two codes are handled differently:
$ cat u.f90
call foo()
contains
subroutine foo(x)
integer, dimension(:), optional :: x
interface
subroutine bar(x)
integer, dimension(:),
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 20:26 ---
so, how 'r' can be used uninitialized in this case?
Because istringstream >> r could have caused an error. so you need to check if
there is an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #3 from pluto at agmk dot net 2007-05-28 20:16 ---
(In reply to comment #2)
> This might not be a bug
>
so, how 'r' can be used uninitialized in this case?
template
R hex_cast ( const std::string & s )
{
if ( s.empty () )
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 20:13 ---
This might not be a bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #1 from pluto at agmk dot net 2007-05-28 20:08 ---
Created an attachment (id=13623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13623&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
attached testcase produces unexpected warning at -O3:
$ g++ -Wall -Woverloaded-virtual -Werror -O3 -gdwarf-2 -g1 -fPIE \
-Wno-error -c auHexCastTest.ii
../../au/h/auHexCast.hpp: In function ‘R au::hex_cast(const
stlp_std::string&) [with R = int]’:
../../au/h/auHexCast.hpp:50: warning: ‘r’ may
Look at this:
$ cat allocate-loop.f90
program main
implicit none
real, allocatable, dimension(:) :: a, b, c
real, dimension(10) :: d, e, f
real :: s
allocate (a(10), b(10), c(10))
call random_number(a)
call random_number(b)
c = a+b
s = sum(c)
print *,s
call random_number(d)
--- Comment #3 from fang at csl dot cornell dot edu 2007-05-28 19:53
---
Yup, also fails with 3.4.0 (accepts-invalid).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-28 19:52 ---
A partial fix can be found at
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01873.html
Some discussions can be found by following the thread.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 ---
Subject: Bug 32100
Author: pinskia
Date: Mon May 28 19:47:53 2007
New Revision: 125140
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125140
Log:
2007-05-28 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-28 19:43 ---
Subject: Bug 32100
Author: pinskia
Date: Mon May 28 19:43:10 2007
New Revision: 125139
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125139
Log:
2007-05-28 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
Hopefully this is everything you need: output from the gfortran
command, the source file, and the .mod and .s files that were
generated. GFORTRAN was installed from binary using fink a day or so
ago. Since this was my first use of fink, I'm not sure why it got the
experimental version.
$ unam
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:08 ---
(In reply to comment #6)
> This is very useful for compilers generating C code (e.g. LLVM, and various
> other source -> C compilers). Why remove it? These compilers are generating
> partially structured code, that
--- Comment #4 from eedelman at gcc dot gnu dot org 2007-05-28 18:51
---
(In reply to comment #3)
> (In reply to comment #2)
> > Created an attachment (id=13618)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618&action=view) [edit]
> > decl.c patch (not check-gfortran tested)
>
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-28 18:13 ---
Some debugging shows:
resolve_call calls resolve_actual_arglist, which fails.
resolve_call propagates the failure to resolve_where, which does not check for
errors.
In resolve_actual_arglist it fails here:
i
--- Comment #108 from funtoos at yahoo dot com 2007-05-28 17:47 ---
but comments in bug 20218 say that its fixed in mainline, which means there was
a fix put into gcc for hidden visibility. So, are both the fix from prerelease
binutils and gcc mainline needed to fix this completely?
--
--- Comment #6 from sabre at nondot dot org 2007-05-28 17:44 ---
This is very useful for compilers generating C code (e.g. LLVM, and various
other source -> C compilers). Why remove it? These compilers are generating
partially structured code, that don't have syntactic blocks required
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-28 17:42 ---
I know what the trouble is:
Since the variable 'a' is not used, the equivalence is scrubbed and the
compiler goes off to look for a module variable, rather than a member of an
external union.
I have tried one or two
--- Comment #163 from ian at airs dot com 2007-05-28 17:30 ---
Richi, I tested my patch on every test case I saved. Can you just point me at
the one I missed? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
Starting with the patch
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html>, committed as
revision 12, linking fails. From libffi/configure.log:
configure:2261: checking for C compiler default output file name
configure:2264: /home/rask/build/gcc-ppc/./gcc/xgcc
-B/home/rask/build/gcc-ppc/
This is kind of a split up of PR31564, which is unrelated.
The program is invalid as we pass an array as actual argument to the scalar
dummy argument; somehow gfortran does not detect this.
Interestingly, compare_actual_formal is never called if the actual argument is
an array section with non-ex
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32128
The following invalid code snippet triggers an ICE on mainline:
template struct A;
template struct A {};
A a;
bug.cc:3: error: parameter pack argument 'T ...' must be at the end of
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32127
The following invalid code snippet triggers an ICE on mainline:
template struct A
{
static T i;
};
int j = A::i;
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3:
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-05-28 17:02 ---
Subject: Bug 31717
Author: bkoz
Date: Mon May 28 17:02:30 2007
New Revision: 125134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125134
Log:
2007-05-28 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
The following invalid code snippet triggers an ICE on mainline:
template struct A;
template struct A
{
static int i;
};
A a;
A b;
bug.cc:3: error: parameter packs not expanded wit
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-05-28 16:58 ---
This path:
$GCC_SRC_ROOT\mingw_build\mingw32\libstdc++-v3\include\ext\pb_ds\detail
Looks wrong. Are you building in the source directory?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32092
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-05-28 16:57 ---
This should do it. I'll put it on 4.2.x branch after some testing on mainline.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
--- Comment #7 from bkoz at gcc dot gnu dot org 2007-05-28 16:56 ---
Created an attachment (id=13622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13622&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-05-28 16:53
---
A similar testcase crashes in a different place:
template struct A;
template struct A
{
A() {}
};
===
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
The following invalid code snippet triggers an ICE on mainline:
template struct A;
template struct A
{
A();
A(T);
};
bug.cc:3: error: parameter packs not expanded with `...':
bug
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-28 16:41 ---
Fixed in GCC 4.3.0, won't backport to 4.2.0 (no regression)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-28 16:39 ---
Subject: Bug 32124
Author: burnus
Date: Mon May 28 16:39:35 2007
New Revision: 125133
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125133
Log:
2007-05-28 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:38
---
Patch was approved...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:17
---
Removing the wrong-code keyword until we manage to find if it actually happens
on 4.2, or if it's just not exposed. I'm reluctant to backport the patch unless
we have a proof of it happening on 4.2 (and if it hap
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #3 from eedelman at gcc dot gnu dot org 2007-05-28 15:41
---
(In reply to comment #2)
> Created an attachment (id=13618)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618&action=view) [edit]
> decl.c patch (not check-gfortran tested)
>
> Erik, are you still working
--- Comment #3 from patchapp at dberlin dot org 2007-05-28 13:15 ---
Subject: Bug number PR32124
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/msg01870.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-28 12:54 ---
Worse, with __builtin_sin(M_PI), I get an error:
test.c:2: error: initializer element is not constant
Maybe this is fixed now in GCC 4.3 by using MPFR.
--
manu at gcc dot gnu dot org changed:
What|
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-28 12:28 ---
Confirmed. Another mangling problem:
Program received signal SIGSEGV, Segmentation fault.
0x0827e9b8 in write_expression (expr=0xb7cdd870)
at /home/richard/src/trunk2/gcc/cp/mangle.c:2175
warning: Source file i
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-28 12:23 ---
Created an attachment (id=13621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13621&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-28 12:07 ---
I had to change huge(1_4) to huge(1_8) as the former was not enough to trigger
an allocation error on my system.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #107 from simon dot strandman at telia dot com 2007-05-28
11:49 ---
(In reply to comment #106)
> I haven't tried the fix in 20218. surprisingly, moving to binutils
> 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is
> going on? how did the latest bin
--- Comment #162 from dberlin at gcc dot gnu dot org 2007-05-28 11:24
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 28 May 2007 11:14:20 -, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #161
--- Comment #161 from rguenther at suse dot de 2007-05-28 11:14 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
Btw, it could save us many bugs (or bug reports) if if PTA says must-alias
we'd trust it, instead of using TBAA to
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-28 10:29 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-28 10:27 ---
Confirmed. Maybe fixed by sccvn.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sfilippone at uniroma2 dot it 2007-05-28 09:35 ---
Created an attachment (id=13620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13620&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
The attached program never reaches the error message printout, contrary to the
fact that stat= is specified in the allocate statement (if the runtime aborts,
what's the point of stat= ?)
[EMAIL PROTECTED] bugtest]$ gfortran -o tryalloc tryalloc.f90
[EMAIL PROTECTED] bugtest]$ ./tryalloc
Fortran ru
--- Comment #16 from rob1weld at aol dot com 2007-05-28 08:35 ---
>> Comment #11 From [EMAIL PROTECTED] 2007-05-27 07:24
>> Getting stuck at ?:
>> libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o"
> ...
>This isn't a fix.
Actually I tought if you had got that far th
--- Comment #1 from ubizjak at gmail dot com 2007-05-28 08:35 ---
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
void sse2_test (void)
{
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 07:58 ---
I think the problem now is related to data-ref and I think this might get fixed
after I fix PR 32075.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
1 - 100 of 108 matches
Mail list logo
