--- Comment #10 from irar at gcc dot gnu dot org 2008-09-07 07:15 ---
Subject: Bug 36630
Author: irar
Date: Sun Sep 7 07:14:03 2008
New Revision: 140081
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140081
Log:
PR tree-optimization/36630
* tree-vect-transform.c
--- Comment #3 from victork at gcc dot gnu dot org 2008-09-07 07:35 ---
Subject: Bug 37334
Author: victork
Date: Sun Sep 7 07:34:30 2008
New Revision: 140082
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140082
Log:
2008-09-07 Victor Kaplansky <[EMAIL PROTECTED]>
PR
--- Comment #1 from burnus at gcc dot gnu dot org 2008-09-07 07:50 ---
The problem is that for
implicit character(len=*,kind=kind('A')) (Q)
the length of the first parameter string is used everywhere. The following
fixes it, but I have no idea why it is a regression / why it worked be
--- Comment #27 from linuxl4 at sohu dot com 2008-09-07 08:25 ---
somebody fix it please.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-07 08:34 ---
(In reply to comment #1)
> The problem is that for
>implicit character(len=*,kind=kind('A')) (Q)
> the length of the first parameter string is used everywhere. The following
> fixes it, but I have no idea why it is
--- Comment #18 from irar at gcc dot gnu dot org 2008-09-07 08:55 ---
Subject: Bug 35642
Author: irar
Date: Sun Sep 7 08:54:00 2008
New Revision: 140083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140083
Log:
PR tree-optimization/35642
* config/rs6000/altive
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-09-07 09:12 ---
I'm working on the run-time test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37203
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-07 09:13 ---
Subject: Re: [4.4 Regression] implicit
character(len=*,kind=kind('A')) (Q) ... no longer gives the right answer.
> But your patch looks good, just intuitively...
The patch works as expected, at least on my quick t
--- Comment #2 from charlet at gcc dot gnu dot org 2008-09-07 09:39 ---
This is a bug in your base compiler, not in GCC 4.4.0.
See other past reports on this issue, where the bug was in the distributor
(Debian ?) compiler, and not in any official GCC releases.
Arno
--
charlet at gcc
--- Comment #11 from irar at gcc dot gnu dot org 2008-09-07 10:07 ---
Subject: Bug 36630
Author: irar
Date: Sun Sep 7 10:05:37 2008
New Revision: 140085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140085
Log:
PR tree-optimization/36630
* tree-vect-transform.c
--- Comment #19 from irar at il dot ibm dot com 2008-09-07 11:05 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #12 from irar at il dot ibm dot com 2008-09-07 11:05 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
Hi !
I get an internal error that tells me to ask you for help :
gfortran -c -g -fconvert=big-endian -frecord-marker=4 gbytes.f
gbytes.f:4: erreur interne du compilateur: dans error_print, ÃÂ
fortran/error.c:471
Veuillez soumettre un rapport complet d'anomalies,
avec le source pré-traitÃÂ
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-09-07 13:34 ---
Subject: Bug 37203
Author: tkoenig
Date: Sun Sep 7 13:33:18 2008
New Revision: 140086
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140086
Log:
2008-09-07 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-09-07 13:54 ---
4.2.1 is rather old.
Using 4.2.4 (Debian 4.2.4-3) on the same code, I get
$ gfortran-4.2 -c -g -fconvert=big-endian -frecord-marker=4 bytes.f
bytes.f:36.65:
+Z'1FFF',Z'3FFF',Z'7FFF',Z'
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-09-07 13:58
---
> See
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00384.html
>
> Mainline can bootstrap with i586-linux. But there are some additional
> testsuite failures.
Thanks for trying to reproduce, this is very
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #2 from preuter64 at yahoo dot de 2008-09-07 14:12 ---
Subject: Re: gbytes.f:4: erreur interne du compilateur:
dans error_print, X
Dear!
The option does the trick, and the program compiles !
Thanks for your help!
Patrick
tkoenig at gcc dot gnu dot org <[EMAI
--- Comment #5 from patriciak784-gccmainling at yahoo dot de 2008-09-07
14:41 ---
Sorry, my "patch" doesn't always fix the problem. It is just strange. Sometimes
it works, sometimes not...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-07 14:46 ---
parm.12.dim[0].ubound = D.1541;
parm.12.dim[0].stride = NON_LVALUE_EXPR ;
parm.12.data = (void *) &(*ifm.11)[0];
parm.12.offset = NON_LVALUE_EXPR ;
D.1547 = MAX_EXPR <(parm.12.dim[0].ubound - p
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-09-07 15:45
---
Created an attachment (id=16247)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16247&action=view)
Simplified testcase.
It is still big, but only 2 functions eventually reach IRA.
Compile with -O2 -fomit-fr
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-09-07 16:01
---
The problem is the 4th line in
Remove r222:a590->a10(mem)
Remove r69:a566->a389(mem)
Remove r69:a549->a389(mem)
Remove r376:a432->a12(mem)
Remove r220:a148->a9(mem)
(r373 is now r3
--- Comment #28 from sgk at troutmask dot apl dot washington dot edu
2008-09-07 16:33 ---
Subject: Re: Implied do-loop in an initialization expression is broken
On Sun, Sep 07, 2008 at 08:25:54AM -, linuxl4 at sohu dot com wrote:
>
> somebody fix it please.
>
If it were easy to
This is broken during sched2 pass. Compiled with -m64 -O2.
lwz 10,1492(7) # nargs,<--- uninitialized
std 9,1272(7)# specpdl.19,
li 9,16 # iftmp.21,
std 3,1488(7)# nargs, nargs
std 4,1496(7)# args, args
cmpwi 7,10,3 #,
--- Comment #1 from schwab at suse dot de 2008-09-07 16:48 ---
Created an attachment (id=16248)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16248&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37408
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-07 17:18 ---
(In reply to comment #2)
> The option does the trick, and the program compiles !
Closed the bug based on this comment.
--
burnus at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #3 from daney at gcc dot gnu dot org 2008-09-07 17:30 ---
It is also working on r140069
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00612.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395
--- Comment #11 from daney at gcc dot gnu dot org 2008-09-07 17:32 ---
Can we close this now?
I think it is fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c-O3
-fwhole-
program -combine -fipa-type-escape -fprofile-generate -lm -o
/test/gnu/gcc/ob
jdir/gcc/testsuite/gcc/w_prof_global_array.x01(timeo
DW_TAG_imported_module (c++ `using namespace') has validity only in the same
block in which they are stated. It works right for the compiled code but it
gets defined for the whole function in DWARF.
DW_TAG_imported_module should be located in DW_TAG_lexical_block. Without the
`int block_create;'
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-09-07 17:56
---
Created an attachment (id=16249)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16249&action=view)
Testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
--- Comment #2 from dominiq at lps dot ens dot fr 2008-09-07 18:25 ---
Confirmed on http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00195.html and
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00505.html.
This looks like a missing or wrong initialisation.
--
http://gcc.gnu.org/
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-07 18:35 ---
Note that in the window 139588 to 139622 there is no change in gfortran. The
most important change is the IRA merge at 139590. This may have caused a
miscompilation of some gfortran code (this happened with transfer)
The following module file causes gfortran to give segmentation fault.
Specifically, given the command "gfortran -c b1.f90" produces:
b1.f90: In function 'sub':
b1:12: internal compiler error: Segmentation fault
This happens with several different versions of the compiler (4.3.1, 4.3.0,
4.2.3,
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-07 19:00 ---
program bounds_issue
real, pointer :: pdf0(:)
allocate(pdf0(0:282))
pdf0 = f(pdf0)
contains
function f(x)
real, intent(in) :: x(0:) ! x(1:), f(1:...) works
real :: f(0:ubou
--- Comment #1 from dominiq at lps dot ens dot fr 2008-09-07 19:01 ---
Confirmed on powerpc-apple-darwin9 (4.2.3, 4.3.2 and trunk):
pr37411.f90: In function 'sub':
pr37411.f90:12: internal compiler error: Bus error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37411
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-07 19:07 ---
It looks like this option can be removed in the LINK_SPEC define.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-07 20:06 ---
Adding -mno-sched-ar-data-spec fixes the crash. This bug is
introduced by selective scheduling.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
Sent from my iPhone
On Sep 7, 2008, at 9:47, "schwab at suse dot de" <[EMAIL PROTECTED]
> wrote:
This is broken during sched2 pass. Compiled with -m64 -O2.
lwz 10,1492(7) # nargs,<--- uninitialized
std 9,1272(7)# specpdl.19,
li 9,16 # iftmp.21,
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-07 20:09 ---
==17304== Invalid read of size 4
==17304==at 0x49F779: gfc_conv_array_parameter (trans-array.c:5179)
==17304==by 0x4B05C0: gfc_conv_function_call (trans-expr.c:2582)
==17304==by 0x4B1A7D: gfc_conv_function
--- Comment #2 from pinskia at gmail dot com 2008-09-07 20:10 ---
Subject: Re: New: [4.3/4.4 regression] Invalid insn scheduling
Sent from my iPhone
On Sep 7, 2008, at 9:47, "schwab at suse dot de" <[EMAIL PROTECTED]
> wrote:
> This is broken during sched2 pass. Compiled with -
--- Comment #5 from hjl dot tools at gmail dot com 2008-09-07 20:11 ---
--- gcc/opts.c.over 2008-09-07 12:50:39.0 -0700
+++ gcc/opts.c 2008-09-07 12:47:04.0 -0700
@@ -1001,13 +1001,13 @@ decode_options (unsigned int argc, const
flag_unwind_tables = targetm.unw
--- Comment #3 from schwab at suse dot de 2008-09-07 20:29 ---
The corresponding code line:
register const unsigned char **new_argv
= (const unsigned char **) __builtin_alloca 2) > (nargs - 2) ? (2) :
(nargs - 2))) * sizeof (char *));
--
http://gcc.gnu.org/bugzilla/show_b
The following program compiles OK with no message that st is being redefined.
function fun() result(st)
character(2) st
character(1) st
st = '1'
end function fun
--
Summary: No error on repeated declaration
Product: gcc
Version: 4.3.0
Status: U
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-07 21:10 ---
Regtests passed without regressions on i686-apple-darwin9. Thanks again for the
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37400
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconf
--- Comment #1 from dominiq at lps dot ens dot fr 2008-09-07 21:15 ---
Confirmed with 4.2.3 and 4.3.2, with 4.4.0 (trunk) I get:
[ibook-dhum] f90/bug% gfc -Wall pr37412.f90
pr37412.f90:3.17:
character(1) st
1
Warning: Symbol 'st' at (1) already has basic type of CHARA
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-07 21:35 ---
(In reply to comment #1)
> Warning: Symbol 'st' at (1) already has basic type of CHARACTER
I think one should print here an error as the LEN type parameter is different.
The same issue exists for the KIND type para
$ cat bug.cc
#define __STDC_LIMIT_MACROS
#ifdef __STDC_LIMIT_MACROS
#undef __STDC_LIMIT_MACROS
#endif
$ g++ -W -Wall -c bug.cc
bug.cc:4:8: warning: undefining "__STDC_LIMIT_MACROS"
$ g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-07 22:06 ---
With -std=f95 all the gfortran versions I have reject the code with:
[ibook-dhum] f90/bug% gfc -std=f95 pr37412.f90
pr37412.f90:3.17:
character(1) st
1
Error: Symbol 'st' at (1) already has basic t
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-07 22:14 ---
*** Bug 37413 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 2008-09-07 22:14 ---
*** This bug has been marked as a duplicate of 34859 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The following code snippet triggers an ICE on mainline (i686-pc-linux-gnu)#
when compiled with "-ffast-math":
===
double foo(double x) { return x; }
double y = 2*foo(1);
===
bug0.cc:2: internal compiler error: Segmentation fa
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37414
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-09-07 23:17
---
*** This bug has been marked as a duplicate of 37348 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-09-07 23:17
---
*** Bug 30156 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Compiling an arbitrary program with "-ftree-store-ccp" triggers an ICE
on mainline:
cc1: internal compiler error: in common_handle_option, at opts.c:2068
Please submit a full bug report, [etc.]
Richard, this seems to be fallout from your patch:
2008-08-29 Richard Guenther <[EMAIL PROTECTED]>
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37415
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-07 23:38 ---
Just like PR 34317 and PR 34382.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from petermorgan at grapevine dot net dot au 2008-09-07
23:56 ---
Subject: Re: [4.3 Regression] gfortran errors
in compilation and the making for upgraded compilers
Dear Andrew
Thanks message below. Unfortunately this is not the correct test case.
The test case invo
--- Comment #6 from hjl dot tools at gmail dot com 2008-09-08 00:04 ---
We have OPTIMIZATION_OPTIONS which is executed once just after
the optimization level is determined and before the remainder
of the command options have been parsed. This macro is run once
at program startup and when
--- Comment #16 from petermorgan at grapevine dot net dot au 2008-09-08
00:43 ---
Created an attachment (id=16250)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16250&action=view)
An updated code fragment, old version tsummc00.f, showing the compilation
error.
A smaller code frag
--- Comment #2 from danglin at gcc dot gnu dot org 2008-09-08 04:27 ---
Subject: Bug 37409
Author: danglin
Date: Mon Sep 8 04:26:15 2008
New Revision: 140099
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140099
Log:
PR driver/37409
* pa-hpux.h (LINK_SPEC): Stri
--- Comment #3 from danglin at gcc dot gnu dot org 2008-09-08 04:34 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37409
--- Comment #6 from christian dot joensson at gmail dot com 2008-09-08
05:30 ---
Subject: Re: FAIL: gcc.c-torture/unsorted/DFcmp.c & SFset.c: internal compiler
error: in extract_insn, at recog.c:2077
> I've seen these in 4.3-based toolchains, but don't see them with recent trunk.
> Do
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-08 06:36 ---
IIRC, this behaviour is due to a patch I submitted some time ago. Maybe I
could change this warning into an error even for non-standard conforming mode
in case the length or a kind parameter differs. What do you thin
For the loop in testcase of pr36630:
void
foo (unsigned char *x, short y)
{
short i;
i = 2;
while (i < y)
{
x[i - 1] = x[i];
i = i + 1;
}
}
we used to get
# of iterations (short unsigned int) y_3(D) + 65533, bounded by 32764
and now we get scev_not_known.
Also Sebasti
--- Comment #1 from ubizjak at gmail dot com 2008-09-08 06:50 ---
Confirmed:
Program received signal SIGSEGV, Segmentation fault.
0x082ac655 in optimize_function_for_speed_p (fun=0x0) at
../../gcc-svn/trunk/gcc/predict.c:205
/home/uros/gcc-svn/trunk/gcc/predict.c:205:6178:beg:0x82ac655
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-08 06:51 ---
Given http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00370.html
I think we can safely close this now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
Reminder from: bebas-promosi Yahoo! Group
http://groups.yahoo.com/group/bebas-promosi/cal
Bahagiakan keluarga anda !!!
Monday September 8, 2008
7:00 am - 8:00 am
(This event repeats every day.)
(The next reminder for this event will be sent in 5 hours, 48 minutes.)
Notes:
Apabila Anda mengin
70 matches
Mail list logo
