--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
encode-2.mm produces "Vec=ffi" for its enconding of @encode(Vec).
which is wrong, it should produce "Vec=ffi".
This was caused by:
2007-02-22 Michael Matz <[EMAIL PROTECTED]>
PR c++/29433
* cp-tree.h (TFF_UNQUALIFIED_NAME): New formatting flag.
* error.c (dump_aggr_type
--- Comment #4 from liqin at gcc dot gnu dot org 2007-05-23 07:35 ---
* config/score/score.c (score_print_operand): makes sure that only
lower bits are used.
--
liqin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from liqin at gcc dot gnu dot org 2007-05-23 07:31 ---
* config/score/misc.md (bitclr_c, bitset_c, bittgl_c): remove.
* config/score/predicate.md (const_pow2, const_npow2): remove.
--
liqin at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from liqin at gcc dot gnu dot org 2007-05-23 07:09 ---
Subject: Bug 30987
Author: liqin
Date: Wed May 23 06:09:20 2007
New Revision: 124983
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124983
Log:
2007-05-23 Chen Liqin <[EMAIL PROTECTED]>
PR target/30
--- Comment #3 from liqin at gcc dot gnu dot org 2007-05-23 07:09 ---
Subject: Bug 30474
Author: liqin
Date: Wed May 23 06:09:20 2007
New Revision: 124983
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124983
Log:
2007-05-23 Chen Liqin <[EMAIL PROTECTED]>
PR target/30
--- Comment #7 from liqin at gcc dot gnu dot org 2007-05-23 06:50 ---
Subject: Bug 30987
Author: liqin
Date: Wed May 23 05:49:50 2007
New Revision: 124980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124980
Log:
2007-05-23 Chen Liqin <[EMAIL PROTECTED]>
PR target/30
--- Comment #2 from liqin at gcc dot gnu dot org 2007-05-23 06:50 ---
Subject: Bug 30474
Author: liqin
Date: Wed May 23 05:49:50 2007
New Revision: 124980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124980
Log:
2007-05-23 Chen Liqin <[EMAIL PROTECTED]>
PR target/30
--- Comment #6 from rob1weld at aol dot com 2007-05-23 06:31 ---
Got "mid-air" colision message when clicking submit. I understand this is
closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
--- Comment #5 from rob1weld at aol dot com 2007-05-23 06:29 ---
The patch for 4.1.1 was created by simply using the GEM revision 4.1.0 patch on
the release version of the GCC 4.1.1 source. All "hunks" succeeded with minimal
offsets.
The patch for 4.2.1 was created by simply using the G
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-23 06:19 ---
First you need a copyright assignment from the GEM guys, second you need to
follow exactly what is on http://gcc.gnu.org/contribute.html, no ifs ands or
buts. Third, there is no testcases. Fourth this patch is not
--- Comment #3 from rob1weld at aol dot com 2007-05-23 06:07 ---
Created an attachment (id=13606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13606&action=view)
gem-1.7/patch/gem-4.3.0.patch - Add GEM to GCC 4.3.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
--- Comment #2 from rob1weld at aol dot com 2007-05-23 06:07 ---
Created an attachment (id=13605)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13605&action=view)
gem-1.7/patch/gem-4.2.1.patch - Add GEM to GCC 4.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
--- Comment #1 from rob1weld at aol dot com 2007-05-23 06:06 ---
Created an attachment (id=13604)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13604&action=view)
gem-1.7/patch/gem-4.1.1.patch - Add GEM to GCC 4.1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
Page http://gcc.gnu.org/readings.html links to "GNU C Compiler Internals
(Wikibook)" http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals , which in
turn links to: "GNU C Compiler Internals/GEM Framework 4 1"
http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GEM_Framework_4_1 .
On that page,
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-05-23 05:19
---
Fixed this regression on 4.2, closing now
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2007-05-23 05:15
---
Subject: Bug 18923
Author: jvdelisle
Date: Wed May 23 04:15:25 2007
New Revision: 124979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124979
Log:
2007-05-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-23 04:15
---
Subject: Bug 31051
Author: jvdelisle
Date: Wed May 23 03:14:35 2007
New Revision: 124978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124978
Log:
2007-05-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-23 03:24
---
Subject: Bug 31051
Author: jvdelisle
Date: Wed May 23 02:24:31 2007
New Revision: 124977
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124977
Log:
2007-05-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-23 03:18 ---
Ok, what is going on here has to deal with how select/case works for strings.
What the front-end produces confuses the crazy out of the middle-end and the
middle-end does not know where the jumps can go so it assum
--- Comment #7 from David dot Duffy at qimr dot edu dot au 2007-05-23
02:37 ---
Subject: Re: improve error message for using specification
expr. of later decl.
On Wed, 22 May 2007, burnus at gcc dot gnu dot org wrote:
> I think gfortran rightly rejects the file though the error mess
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-05-23 02:26
---
I can no longer reproduce this issue on the mainline, at least with the reduced
testcase or with the orginal reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-05-23 02:17
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-23 02:17
---
Subject: Bug 31095
Author: pinskia
Date: Wed May 23 01:17:14 2007
New Revision: 124975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124975
Log:
2007-05-22 Andrew Pinski <[EMAIL PROTECTED]>
PR
CC: (GNU) 4.3.0 20070522 (experimental)"
.section.note.GNU-stack,"",@progbits
real0m16.433s
user0m16.425s
sys 0m0.004s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
--- Comment #6 from manu at gcc dot gnu dot org 2007-05-23 01:50 ---
(In reply to comment #4)
> (convert_like_real gives me the creeps.)
>
> I must check whether this warning has been taken by the new Wconversion, which
> is not currently enabled by Wall.
>
By the way, this is not en
--- Comment #5 from manu at gcc dot gnu dot org 2007-05-23 01:49 ---
(In reply to comment #3)
>(3) since __null is of type int, the cast to int was a no-op, and
>since the C++ front-end currently does not have a high level
>representation of the program (e.g. lowerin
--- Comment #4 from aaw at gcc dot gnu dot org 2007-05-23 01:19 ---
*** Bug 2708 has been marked as a duplicate of this bug. ***
--
aaw at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from aaw at gcc dot gnu dot org 2007-05-23 01:19 ---
*** This bug has been marked as a duplicate of 30734 ***
--
aaw at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from aaw at gcc dot gnu dot org 2007-05-23 01:16 ---
Resolved by r124960 (cf.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01182.html).
--
aaw at gcc dot gnu dot org changed:
What|Removed |Added
--
popl%ecx
popl%ebp
leal-4(%ecx), %esp
ret
.size main, .-main
.local sec.1647
.comm sec.1647,4,4
.local nsec.1646
.comm nsec.1646,8,8
.ident "GCC: (GNU) 4.3.0 20070522 (experimental)"
.sect
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-23
00:57 ---
Subject: Re: [4.3 Regression] misc.c:899: error: 'const struct real_format'
has no member named 'log2_b'
> Fixed by:
> http://gcc.gnu.org/viewcvs?view=rev&revision=124938
Thanks,
Dave
--
http://gcc.g
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-23 00:48 ---
The patch which I am testing:
Index: testsuite/gcc.dg/boolcomplex-1.c
===
--- testsuite/gcc.dg/boolcomplex-1.c(revision 0)
+++ testsuite/gcc.dg/bool
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-23 00:33 ---
Janis, can you run a regression hunt on this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-23 00:32 ---
On the trunk with -Os -ftree-vectorize -m64 -maltivec, I get:
t.c: In function ‘fill_table_dc00_d800’:
t.c:6: internal compiler error: in vect_transform_loop, at
tree-vect-transform.c:5263
Please submit a full bu
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-23 00:29 ---
I have a patch for the C and C++ front-ends, we don't have to change fold at
all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-23 00:27 ---
(In reply to comment #8)
> gcc dropped a lot of features which weren't included in standard recently and
> thus many of us wondering why the code which compiled before doesn't compile
> now. It's fine for me to have
--- Comment #8 from nshmyrev at yandex dot ru 2007-05-23 00:12 ---
The point I'm trying to express is that it's useful for user to have more
precise explanation.
gcc dropped a lot of features which weren't included in standard recently and
thus many of us wondering why the code which co
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-23 00:05 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
t;
PR middle-end/31606
* gcc.c-torture/20070522-1.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.c-torture/20070522-1.c
Modified:
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31606
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-22 23:58 ---
Fixed by:
2007-04-30 Alexandre Oliva <[EMAIL PROTECTED]>
PR middle-end/22156
Temporarily revert:
I will apply a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
gfortran -m32 -march=opteron -ftree-vectorize -O3 gas_dyn.f90
gas_dyn.f90: In function 'keel':
gas_dyn.f90:435: internal compiler error: Segmentation fault
Works with -m64, -O2 and no -ftree-vectorize.
This is with 4.3.0 20070522 (plus patch of PR 32018) on
x86_64-unknown-linux-gn
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-05-22 23:48 ---
I can't reproduce this on 4.0.4. Perhaps it had happened to an interim
version of 4.0. I'd like to close this PR as FIXED.
--
kkojima at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-22 23:35 ---
Seems to be fixed by the patch for PR 32018. I will bootstrap and retest
tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32006
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-22 23:26 ---
Janis can you do a regression hunt on this bug.
Here is a powerpc testcase if you need one:
int
foo (void)
{
unsigned int resultvar;
long int arg = (long int) 0;
register long int reg asm ("r3") = arg;
asm (
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-22 23:25 ---
Janis can you do a regression hunt on 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-22 23:24 ---
Fixed, unknown by what.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
GCC build triplet|x86_64-unknown-linux-gnu|
GCC host tr
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 23:18 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from ian at airs dot com 2007-05-22 23:18 ---
The bug report as stated is clearly incorrect. gcc is perfectly free to insert
calls to __udivdi3. This is not forbidden by any part of the C language
standards.
To clarify for future readers, I gather that the actual proble
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 23:17 ---
(In reply to comment #2)
> Confirmed. Possibly another missing has_volatile_ops.
Yes in the inliner :)
Here is a testcase for -O2:
struct shparam
{
char **p;
};
static inline void freeparam (volatile struct shpar
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-22 23:15 ---
The patch causing this regression is
r124727 | rakdver | 2007-05-14 23:58:42 +0200 (Mo, 14 Mai 2007) | 46 lines
http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00425.html
Zdenek, could you have a look?
--
burnus at gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-22 23:13 ---
We are deleting the whole basic block.
Steven, I think this is related to one of your cfg basic block changes, can you
take a look?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-22 23:10 ---
And it is the same as my patch fixes the problem also so closing as a dup.
*** This bug has been marked as a duplicate of 30564 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-05-22 23:10
---
*** Bug 32033 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 23:08 ---
I know what this issue is. This is most likely the same issue as PR 30564,
which I need to get around to fixing still.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 23:02 ---
Fortran has no concept of NaN except in Fortran 2003 IEEE module. To say it in
the words of Dick Hendrickson (cf. PR 30694): "A program is prohibited from
invoking an intrinsic procedure under circumstances where a va
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-05-22 22:58 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01500.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 22:52 ---
> I guess the next GCC version will add new hints and readme's ...
> A nightmare for administrators.
This has been true since at least 3.3 so I don't understand why you think this
is a new problem. Solaris's /bin/s
--- Comment #4 from vincent at vinc17 dot org 2007-05-22 22:50 ---
(In reply to comment #3)
> My recollection is that the special -I behavior is there because
> the system headers have special non-warning properties.
> This situation doesn't apply to -L.
But this introduces an inconsist
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 22:50 ---
And NaN is unordered which causes the results to become undefined unless you
have a defined value for min/max in the standard (fmin/fmax in C99 have a
defined value of having NaN being a missing value).
--
http:
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-05-22 22:48
---
Index: builtins.c
===
Here is the patch which fixes the problem:
--- builtins.c (revision 124965)
+++ builtins.c (working copy)
@@ -3485,6 +3485,7 @
--- Comment #2 from =?ISO-8859-1?Q?Andr=E9_Schneider?=
2007-05-22 22:47
---
Subject: Re: unknown option -e for test command in gen-classlist.sh
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 18:36
> ---
> You did not f
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-22 22:41 ---
Regardless whether NaN is defined, in an ordered set MAX(a, b) should always
equal MAX(b, a).
For the record:
$> ifort pr32048.f90 && ./a.out
2.10
2.10
$> sunf95 -w4 pr32048.f90 && ./a.out
Floating po
--- Comment #3 from aaw at gcc dot gnu dot org 2007-05-22 22:41 ---
Assigning to myself since I now have write access to Bugzilla.
--
aaw at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from patchapp at dberlin dot org 2007-05-22 22:38 ---
Subject: Bug number PR32046
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/msg01499.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-22 22:21
---
#5 0x102946e0 in expand_expr_real_1 (exp=0xf7d53630, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /home/apinski/src/ptrplus/gcc/gcc/expr.c:8872
(gdb) p debug_generic_expr (exp)
past = t
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 22:07 ---
NaN is not defined in Fortran's real so I am thinking about closing this as
invalid. Only the IEEE types in Fortran 2003 is where NaN are defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32048
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-22 22:04 ---
> (probably the condition check is too conservative
> so this isn't fully cooked yet):
Way too conservative because even if you don't have the opcode, sometimes code
can be produced without calling the libcall.
If y
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-22 21:56 ---
The patch below does the job but needs some sorting out. In particular, the
function call generated by the calculation of the character length needs to be
supressed, in case the function has side effects.
It's regtes
--- Comment #7 from schwab at suse dot de 2007-05-22 21:51 ---
Everything is "according to the standard". That's where C is defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
It would be great if kind=16 could also be supported on x86_64 besides the
kinds 4, 8 and 10. With this some legacy code could be run and we would catch
up with ifort, which support kind 4, 8 and 16. (16 with software emulation.)
Problems:
- software fp is still a bit incomplete
- Supporting kind
--- Comment #6 from nshmyrev at yandex dot ru 2007-05-22 21:36 ---
Ok, add a line:
"According to standard cast is not lvalue"
I'll be happy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
--- Comment #5 from schwab at suse dot de 2007-05-22 21:32 ---
Because the standard says so?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
--- Comment #9 from sje at cup dot hp dot com 2007-05-22 21:27 ---
Is anyone looking at this bug? It seems to have generated a lot of interest.
I can reproduce it on IA64 HP-UX (using the code in comment #1) but when I undo
the change in 119535 (see comment #4) I still get the problem s
--- Comment #3 from spark at gcc dot gnu dot org 2007-05-22 21:11 ---
(In reply to comment #0)
> First I am herewith re-afirming my formal request for Mr. Pinsk to refrain
> from
> having anything to do with my submissions.
Please refrain from insulting others.
> According to my (admi
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-05-22 21:04 ---
Do you plan a backport? If not, we should close this.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-05-22 21:02 ---
After some thoughts, I don't think it is worth backporting to 4.2.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
The test program should consistently return
either 2.1 or NaN:
$ cat foo.f90
program main
real :: nan
nan = 0.0
nan = nan / nan
print *,max(2.1, nan)
print *,max(nan, 2.1)
end program main
$ gfortran foo.f90
$ ./a.out
2.10
NaN
A lot of compilers seem to get this wrong
--- Comment #123 from gdr at cs dot tamu dot edu 2007-05-22 20:53 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mrs at apple dot com" <[EMAIL PROTECTED]> writes:
| I think it is reasonable to push the tighening language into
--- Comment #122 from mrs at apple dot com 2007-05-22 20:41 ---
When the standard was originally written, I do think we may have missed out on
some finer points of the C object model, mainly to do with restrictions on what
one is not permitted to do stemming from the declared type. The
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-22 20:33
---
(In reply to comment #5)
> D.1477 = (SAVE_EXPR <() (MAX_EXPR + -1) +
> 1>) * 4;
Yup, the following patch fixes it. I think there might be other occurences of
such a problem (basically, every time we use TYPE
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-22 20:14 ---
> It might have to do with stop not being marked as noreturn.
How to mark as noreturn? I mean differently from what is alreay done in
trans-decl.c:
gfor_fndecl_stop_numeric =
gfc_build_library_function_decl (ge
--- Comment #121 from gdr at cs dot tamu dot edu 2007-05-22 20:12 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
[...]
| And, although I don't have the time/energy th
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-05-22 19:50
---
Not a GCC/Gfortran bug so closing as works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-22 19:49 ---
D.1477 = (SAVE_EXPR <() (MAX_EXPR + -1) +
1>) * 4;
int8 D.1477;
We have signed = unsigned * unknown ; I say unknown because I don't know off
the top of my head if 4 is signed or not (I think we should be
--- Comment #10 from magnus_os at yahoo dot se 2007-05-22 19:47 ---
Installing MPFR 2.2.1-p5 helped. gfortran doesn't fail anymore. Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31971
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 19:45 ---
FX, it seems that your patch contains mismatch types, which cause the wrong
code with -O2. At least if I revert your allocate patch, it no longer fails.
r124721 | fxcoudert | 2007-05-14 21:33:57 +0200 (Mon, 14 May 20
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-22 19:28 ---
Same error, but now for a valid program. Compiles and runs with NAG f95, g95
and ifort.
module test1
implicit none
contains
character(f()) function test2() result(r)
interface
pure function f()
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-22 19:14 ---
Created an attachment (id=13603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13603&action=view)
result_in_spec_1.f90.003t.original
As requested: The -fdump-tree-original of result_in_spec_1.f90.
It is time th
The following invalid program (based on gfortran.dg/result_in_spec_1.f90 used
to find PR32046) causes an ICE.
NAG f95 duly reports:
Error: result_in_spec_1.f90, line 4: Too few arguments in reference to F
result_in_spec_1.f90: In function 'MAIN__':
result_in_spec_1.f90:21: internal compiler er
--- Comment #3 from tromey at gcc dot gnu dot org 2007-05-22 19:11 ---
My recollection is that the special -I behavior is there because
the system headers have special non-warning properties.
This situation doesn't apply to -L.
> 2. Software is often compiled with configure, make, make
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-22 19:04 ---
I bet this is like the other "Attempt to allocate a negative amount of memory"
and really a front-end issue with respect of mismatch types. Can you attach
-fdump-tree-original dump?
--
pinskia at gcc dot gnu dot
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-22 19:00 ---
Missed to write that the regression occured beween 2007-05-14-r124708 (working)
and 2007-05-15-r124736 (failing).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32046
The following examples run fine with -O1, but with -O2 they gfortran library
gives an error at run time.
$ gfortran -O gfortran.dg/interface_12.f90
$ ./a.out
$ gfortran -O2 gfortran.dg/interface_12.f90
$ ./a.out
Fortran runtime error: Attempt to allocate a negative amount of memory.
Analogously f
--- Comment #120 from mark at codesourcery dot com 2007-05-22 18:55 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> | I would guess
> | that we made this change around the year 2000. So, t
--- Comment #119 from gdr at cs dot tamu dot edu 2007-05-22 18:40 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 18:36 ---
You did not follow the instructions on installation
(http://gcc.gnu.org/install/):
The Solaris 2 /bin/sh will often fail to configure libstdc++-v3, boehm-gc or
libjava. We therefore recommend using the following ini
--- Comment #118 from mark at codesourcery dot com 2007-05-22 18:34 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> Thanks for reminding all those points. I'll ensure that I make those
> po
1 - 100 of 198 matches
Mail list logo
