[Bug fortran/34536] New: Make support of 2.0**-3*5 tighter: Print warning by default
The problem with 2.0**-3*5 is whether it should be interpreted as 2.0**(-3) * 5 or as 2.0**(-3*5). gfortran does the former, ifort the latter. g95, openf95, sunf95 and (of cause) NAG f95 reject it always. ifort: Accepts it, unless -stand f* is used. gfortran: Warning for -pedantic, Error for -std=f*. Nothing for -Wall. I would suggest to print at least a warning by default; or to shift it to legacy, but having it without diagnostics by default can lead to wrong results. -- Summary: Make support of 2.0**-3*5 tighter: Print warning by default Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34536
[Bug fortran/34536] Make support of 2.0**-3*5 tighter: Print warning by default
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-20 08:04 --- See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/30039cbb71280a3b/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34536
[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors
--- Comment #12 from burnus at gcc dot gnu dot org 2007-12-20 08:13 --- Subject: Bug 34482 Author: burnus Date: Thu Dec 20 08:13:09 2007 New Revision: 131098 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131098 Log: 2007-12-20 Tobias Burnus [EMAIL PROTECTED] PR fortran/34482 * gfortran.texi (BOZ): Document behavior for complex numbers. * target-memory.h (gfc_convert_boz): Update prototype. * target-memory.c (gfc_convert_boz): Add error check and convert BOZ to smallest possible bit size. * resolve.c (resolve_ordinary_assign): Check return value. * expr.c (gfc_check_assign): Ditto. * simplify.c (simplify_cmplx, gfc_simplify_dble, gfc_simplify_float, gfc_simplify_real): Ditto. 2007-12-20 Tobias Burnus [EMAIL PROTECTED] PR fortran/34482 * gfortran.dg/boz_8.f90: Add error-check check. * gfortran.dg/boz_9.f90: Shorten BOZ where needed, replace stop by call abort. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/boz_8.f90 trunk/gcc/testsuite/gfortran.dg/boz_9.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34482
[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors
--- Comment #13 from burnus at gcc dot gnu dot org 2007-12-20 08:15 --- FIXED on the trunk (4.3.0) [does not affect 4.2.x or 4.1.x]. Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34482
[Bug libfortran/34530] [4.3 regression] namelist read broken when whitespace after namelist
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-20 08:17 --- Subject: Bug 34530 Author: burnus Date: Thu Dec 20 08:16:48 2007 New Revision: 131099 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131099 Log: 2007-12-20 Tobias Burnus [EMAIL PROTECTED] PR fortran/34530 * io/list_read.c (eat_line): Move up in the file. (eat_separator): In namelist mode, skip over comment lines. 2007-12-20 Tobias Burnus [EMAIL PROTECTED] PR fortran/34530 * gfortran.dg/namelist_44.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_44.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
[Bug libfortran/34530] [4.3 regression] namelist read broken when whitespace after namelist
--- Comment #4 from burnus at gcc dot gnu dot org 2007-12-20 08:22 --- FIXED on the trunk (4.3.0). Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
[Bug fortran/34537] New: ICE (FPE) for TRANSFER('string', char_ptr)
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5a1e0cc2c7eb95cc/
character, pointer :: ptr(:)
allocate(ptr(8))
ptr = transfer('Sample'//achar(0),ptr) ! Causes ICE
end
gives a Floating Point Exception.
--
Summary: ICE (FPE) for TRANSFER('string', char_ptr)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 31237,32834
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
[Bug fortran/34537] ICE (FPE) for TRANSFER('string', char_ptr)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-20 08:42 --- gdb shows: Program received signal SIGFPE, Arithmetic exception. 0x0046b86e in gfc_simplify_transfer (source=0x26a7b30, mold=0x1, size=0x0) at /projects/tob/gcc/gcc/fortran/simplify.c:4138 4138 result_length = source_size / result_elt_size; #0 0x0046b86e in gfc_simplify_transfer (source=0x26a7b30, mold=0x1, size=0x0) at /projects/tob/gcc/gcc/fortran/simplify.c:4138 #1 0x0042aec3 in do_simplify (specific=0x2687a10, e=0x26a7a60) at /projects/tob/gcc/gcc/fortran/intrinsic.c:3187 #2 0x0042bd3a in gfc_intrinsic_func_interface (expr=0x26a7a60, error_flag=1) at /projects/tob/gcc/gcc/fortran/intrinsic.c:3446 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
[Bug c++/34459] [4.1/4.3 Regression] incorrect code when compiled with optimization (-O1)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||12/msg00971.html Status|NEW |ASSIGNED Last reconfirmed|2007-12-14 13:32:37 |2007-12-20 09:31:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34459
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #1 from olga at gcc dot gnu dot org 2007-12-20 09:32 --- Would you please provide me with the following: -dump files for all failures (as you did for PR34472) -configuration options you use -at least initial debugging (where it fails) Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug debug/34535] [4.3 Regression] FAIL: libmudflap.c++/fail24-frag.cxx ICE
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-20 10:30 --- Posted 2 alternative patches: http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00983.html http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00985.html (though IMHO both are desirable). -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||12/msg00983.html Status|NEW |ASSIGNED Last reconfirmed|2007-12-20 01:21:25 |2007-12-20 10:30:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34535
[Bug fortran/34537] ICE or wrong code for TRANSFER of constant string to character
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-20 10:57 ---
at /projects/tob/gcc/gcc/fortran/simplify.c:4138
4138 result_length = source_size / result_elt_size;
Here, source_size is correctly 8, but result_elt_size == 0 instead of 1
(character(len=1)).
The following fails at run time (nothing is printed):
program main
implicit none
character(len=8) :: t
call test(t)
print *, t
contains
subroutine test(a)
character(len=*) :: a
a = transfer('Sample',a)
end subroutine test
end program main
The following ill-defined program gives another ICE:
compiler error: in gfc_interpret_character, at fortran/target-memory.c:360
(It is ill defined because the source size is smaller than the result size; cf.
PR 33037. NAG f95 prints Intrinsic TRANSFER has partly undefined result)
program main
implicit none
character(len=8), target :: t
character(len=8), pointer :: p
p = t
call test(p)
print *, t
contains
subroutine test(a)
character(len=8),pointer :: a
a = transfer('Sample',a)
end subroutine test
end program main
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|ICE (FPE) for |ICE or wrong code for
|TRANSFER('string', char_ptr)|TRANSFER of constant string
||to character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
[Bug ada/23583] invalid implemenation of Ada Monotonic_Clock
--- Comment #2 from charlet at gcc dot gnu dot org 2007-12-20 11:26 --- Actually, we do not claim annex d conformance in GCC, so closing this PR, since on linux (which is what this report is referring to), it does not make sense to go to the hardware level. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23583
[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-12-20 11:56 --- Note I also saw this on powerpc-linux-gnu but I have not checked after the patch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34482
[Bug fortran/34536] Make support of 2.0**-3*5 tighter: Print warning by default
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-12-20 12:40 --- See F95, Section 7.4 Precedence of operators, Table 7.8 Exponentation has a higher precedence than multiplication, so 2.0**-3*5 = (2.0**(-3)) * 5 Hence, is a warning really necessary? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34536
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #27 from bonzini at gnu dot org 2007-12-20 13:53 --- I screwed up so I have to rerun most of SPECfp2000, but the results seem a wash. Anybody can fire the patch I'll attach soon on a wide range of machines? -- Bug 17236 depends on bug 6585, which changed state. Bug 6585 Summary: Redundant store/load instruction pairs on ix86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6585 What|Old Value |New Value Status|RESOLVED|ASSIGNED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug fortran/34536] Make support of 2.0**-3*5 tighter: Print warning by default
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-20 14:04 --- Exponentation has a higher precedence than multiplication, so 2.0**-3*5 = (2.0**(-3)) * 5 You forgot about the minus sign. You have: [constant][exponent][minus][constant][times][constant] and not [constant][exponent][level-1 expr][times][constant] (with level-1 expr = ([unary minus][constant]) Thus one can say: [times] comes before [minus] and thus: [2.0][exponent]([minus]([3][times][5]) but one can also claim that the exponent comes first and the user probably meant an unary [minus]: ([2.0][exponent]([minus][3]))[times][5] a) is what intel does (without -stand f03) b) is what gfortran does (without -std=f2003) I cannot find exactly where it is forbidden, but it boils down that expression operator expression is allowed and expression operator operator expression is not. Also all compilers agree that it is non-standard Fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34536
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #28 from bonzini at gnu dot org 2007-12-20 14:15 --- Created an attachment (id=14800) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14800action=view) combined patch -- bonzini at gnu dot org changed: What|Removed |Added Attachment #14793|0 |1 is obsolete|| Attachment #14794|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug fortran/34536] Make support of 2.0**-3*5 tighter: Print warning by default
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-12-20 14:23 ---
You forgot about the minus sign.
Blind spot. If in doubt, I have a habit of putting extra-paranthesis anyway :)
On topic:
Metcalf, Section 3.2, states: [...] a unary minus or plus must not follow
immediately after another operator. When it is needed, as for $x^{-y}$,
parantheses must be placed around the operator and the operand x**(-y).
Agreed, this should not be hidden in -pedantic; we should use -Wall instead or
even a default warning as suggested.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-12-20 14:23:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34536
[Bug tree-optimization/29484] [4.0/4.1/4.2/4.3 Regression] tree-inline.c bug with local static vars
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||12/msg00999.html Status|NEW |ASSIGNED Last reconfirmed|2006-10-16 16:06:40 |2007-12-20 14:32:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29484
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-20 14:32 --- http://gcc.gnu.org/onlinedocs/gfortran/DTIME.html Description: Subsequent invocations of DTIME return values accumulated since the previous invocation. Return value: Elapsed time in seconds since the start of program execution. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug c++/33911] attribute deprecated vs. templates
--- Comment #2 from niemayer at isg dot de 2007-12-20 14:32 ---
I can second that problem for template member functions - in contrast to
non-template member functions, where the attribute works.
This gives a warning about deprecation as expected:
-
struct T { } ;
struct A {
inline void foo(T ) __attribute__((deprecated));
};
inline void A::foo(T ) { }
void test(T t) {
A a;
a.foo(t);
}
-
... while this is not causing a warning as it should:
-
struct A {
template class T inline void foo(T ) __attribute__((deprecated));
};
template class T inline void A::foo(T ) { }
void test(A t) {
A a;
a.foo(t);
}
-
--
niemayer at isg dot de changed:
What|Removed |Added
CC||niemayer at isg dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
[Bug c++/34459] [4.1/4.3 Regression] incorrect code when compiled with optimization (-O1)
--- Comment #7 from jakub at gcc dot gnu dot org 2007-12-20 14:40 --- Subject: Bug 34459 Author: jakub Date: Thu Dec 20 14:40:33 2007 New Revision: 131101 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131101 Log: PR c++/34459 * tree-ssa-dse.c (dse_optimize_stmt): Don't eliminate store if USE_STMT not only stores into the same object as STMT, but might read it too. * gcc.c-torture/execute/20071219-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20071219-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34459
[Bug c++/34459] [4.1 Regression] incorrect code when compiled with optimization (-O1)
--- Comment #8 from jakub at gcc dot gnu dot org 2007-12-20 14:43 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.3 4.3.0 |4.1.3 Known to work|4.2.2 |4.2.2 4.3.0 Summary|[4.1/4.3 Regression]|[4.1 Regression] incorrect |incorrect code when compiled|code when compiled with |with optimization (-O1) |optimization (-O1) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34459
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #43 from zadeck at naturalbridge dot com 2007-12-20 14:49
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52
---
Created an attachment (id=14799)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
memory details for an unpatched mainline
Here is the same information without Steven's two patches for mainline.
Could you add the attached patch in and rerun your example?
It will add 4 lines to indicate what kinds of def-use and use-def chains
are being created.
A lot of the space is being used by these chains and I want to find out
how many of those chains are for artificial uses and defs.
thanks
kenny
Index: df-problems.c
===
--- df-problems.c (revision 131096)
+++ df-problems.c (working copy)
@@ -1855,13 +1855,23 @@ df_live_verify_transfer_functions (void)
#define df_chain_problem_p(FLAG) (((enum
df_chain_flags)df_chain-local_flags)(FLAG))
+static long df_chain_counters[4];
+
/* Create a du or ud chain from SRC to DST and link it into SRC. */
struct df_link *
df_chain_create (struct df_ref *src, struct df_ref *dst)
{
struct df_link *head = DF_REF_CHAIN (src);
- struct df_link *link = pool_alloc (df_chain-block_pool);;
+ struct df_link *link = pool_alloc (df_chain-block_pool);
+ int index = 0;
+
+ if (!src-insn)
+index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+ if (!dst-insn)
+index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+
+ df_chain_counters[index]++;
DF_REF_CHAIN (src) = link;
link-next = head;
@@ -2156,11 +2166,18 @@ df_chain_finalize (bitmap all_blocks)
{
unsigned int bb_index;
bitmap_iterator bi;
-
+
+ memset (df_chain_counters, 0, 4*sizeof(long));
+
EXECUTE_IF_SET_IN_BITMAP (all_blocks, 0, bb_index, bi)
{
df_chain_create_bb (bb_index);
}
+
+ fprintf (stderr, real - real = %ld\n, df_chain_counters[0]);
+ fprintf (stderr, real - art = %ld\n, df_chain_counters[1]);
+ fprintf (stderr, art - real = %ld\n, df_chain_counters[2]);
+ fprintf (stderr, art - art = %ld\n, df_chain_counters[3]);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-20 14:45 --- Subject: Re: [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa Thanks for fixing this so quickly. Actually, I realized last night that I failed to load the function label from memory. I'll try to fix it today. I don't think I'll install the testcase. The reason is there are no complex circumstances around this change. So, once the problem is fixed, I expect it to stay fixed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #45 from zadeck at naturalbridge dot com 2007-12-20 15:31
---
Subject: Re: Inordinate compile times on large
routines
stevenb dot gcc at gmail dot com wrote:
--- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
---
Subject: Re: Inordinate compile times on large routines
On 20 Dec 2007 14:49:12 -, zadeck at naturalbridge dot com
[EMAIL PROTECTED] wrote:
--- Comment #43 from zadeck at naturalbridge dot com 2007-12-20 14:49
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20
03:52 ---
Created an attachment (id=14799)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
memory details for an unpatched mainline
Here is the same information without Steven's two patches for mainline.
Could you add the attached patch in and rerun your example?
It will add 4 lines to indicate what kinds of def-use and use-def chains
are being created.
A lot of the space is being used by these chains and I want to find out
how many of those chains are for artificial uses and defs.
thanks
kenny
struct df_link *
df_chain_create (struct df_ref *src, struct df_ref *dst)
{
struct df_link *head = DF_REF_CHAIN (src);
- struct df_link *link = pool_alloc (df_chain-block_pool);;
+ struct df_link *link = pool_alloc (df_chain-block_pool);
+ int index = 0;
+
+ if (!src-insn)
+index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+ if (!dst-insn)
+index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+
+ df_chain_counters[index]++;
Watch for segfaults. Index will be 1, 2, 3, or 4.
df_chain_counters[4] does not exist.
indexes will be 0, 1, 2, 3.
there are no def-def chains, and in particular there are no artificial
def to artificial def chains. those increments only happen for
artificial defs or uses. Regular uses or defs have an insn. a normal
def-use chain will have index 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
---
Subject: Re: Inordinate compile times on large routines
On 20 Dec 2007 14:49:12 -, zadeck at naturalbridge dot com
[EMAIL PROTECTED] wrote:
--- Comment #43 from zadeck at naturalbridge dot com 2007-12-20 14:49
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20
03:52 ---
Created an attachment (id=14799)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
memory details for an unpatched mainline
Here is the same information without Steven's two patches for mainline.
Could you add the attached patch in and rerun your example?
It will add 4 lines to indicate what kinds of def-use and use-def chains
are being created.
A lot of the space is being used by these chains and I want to find out
how many of those chains are for artificial uses and defs.
thanks
kenny
struct df_link *
df_chain_create (struct df_ref *src, struct df_ref *dst)
{
struct df_link *head = DF_REF_CHAIN (src);
- struct df_link *link = pool_alloc (df_chain-block_pool);;
+ struct df_link *link = pool_alloc (df_chain-block_pool);
+ int index = 0;
+
+ if (!src-insn)
+index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+ if (!dst-insn)
+index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+
+ df_chain_counters[index]++;
Watch for segfaults. Index will be 1, 2, 3, or 4.
df_chain_counters[4] does not exist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #2 from dominiq at lps dot ens dot fr 2007-12-20 15:57 --- Description: Subsequent invocations of DTIME return values accumulated since the previous invocation. Return value: Elapsed time in seconds since the start of program execution. This at best ambiguous and, with my nonnative English, I read it as contradictory: how can the return value be different from the return values. If it means, that the returned value for result in the subroutine version is different from the one for the function, it is clearly user hostile and IMO it does not make sense if these intrinsics are here for compatibility with g77. With g77 the following code program test_dtime integer*8 i, j real tarray(2) real :: result result = dtime(tarray) print *, 'dtime= ', result print *, tarray(1), tarray(2) result = etime(tarray) print *, 'etime= ', result print *, tarray(1), tarray(2) do i=1,1! Just a delay j = i * i - i end do result = dtime(tarray) print *, 'dtime= ', result print *, tarray(1), tarray(2) result = dtime(tarray) print *, 'dtime= ', result print *, tarray(1), tarray(2) result = etime(tarray) print *, 'etime= ', result print *, tarray(1), tarray(2) end program test_dtime gives dtime= 0.0014273 0.00043896 0.00098864 etime= 0.0015622 0.00048791 0.0010743 dtime= 1.02332103 1.02199399 0.0013268 dtime= 4.59344592E-05 2.19345093E-05 2.3499E-05 etime= 1.024827 1.02246404 0.0023637 1.022u 0.002s 0:01.02 100.0%0+0k 0+0io 0pf+0w where the third dtime returns the time difference from the previous call, while gfortran gives dtime= 2.1988E-03 6.2594E-04 1.5729E-03 etime= 2.3796E-03 7.4096E-04 1.6392E-03 dtime= 0.92270601 0.92067999 2.0266E-03 dtime= 0.92281002 0.92073703 2.0725E-03 etime= 0.92285997 0.92076099 2.0982E-03 0.920u 0.002s 0:00.92 100.0%0+0k 0+0io 0pf+0w In my opinion all the intrinsics introduced for compatibility with g77 should behave as they do with g77 (and properly documented) or be removed (Note that I found the problem while looking at PR30388 for which the gfortran timings were inconsistent). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #46 from zadeck at naturalbridge dot com 2007-12-20 16:06
---
Subject: Re: Inordinate compile times on large
routines
indexes will be 0, 1, 2, 3.
there are no def-def chains, and in particular there are no artificial
def to artificial def chains. those increments only happen for
artificial defs or uses. Regular uses or defs have an insn. a normal
def-use chain will have index 0.
however there is a bug with the patch that steven did not notice, try
this one instead.
Index: df-problems.c
===
--- df-problems.c (revision 131096)
+++ df-problems.c (working copy)
@@ -1855,13 +1855,23 @@ df_live_verify_transfer_functions (void)
#define df_chain_problem_p(FLAG) (((enum
df_chain_flags)df_chain-local_flags)(FLAG))
+static long df_chain_counters[4];
+
/* Create a du or ud chain from SRC to DST and link it into SRC. */
struct df_link *
df_chain_create (struct df_ref *src, struct df_ref *dst)
{
struct df_link *head = DF_REF_CHAIN (src);
- struct df_link *link = pool_alloc (df_chain-block_pool);;
+ struct df_link *link = pool_alloc (df_chain-block_pool);
+ int index = 0;
+
+ if (!src-insn)
+index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+ if (!dst-insn)
+index += (dst-type == DF_REF_REG_DEF) ? 2 : 1;
+
+ df_chain_counters[index]++;
DF_REF_CHAIN (src) = link;
link-next = head;
@@ -2156,11 +2166,18 @@ df_chain_finalize (bitmap all_blocks)
{
unsigned int bb_index;
bitmap_iterator bi;
-
+
+ memset (df_chain_counters, 0, 4*sizeof(long));
+
EXECUTE_IF_SET_IN_BITMAP (all_blocks, 0, bb_index, bi)
{
df_chain_create_bb (bb_index);
}
+
+ fprintf (stderr, real - real = %ld\n, df_chain_counters[0]);
+ fprintf (stderr, real - art = %ld\n, df_chain_counters[1]);
+ fprintf (stderr, art - real = %ld\n, df_chain_counters[2]);
+ fprintf (stderr, art - art = %ld\n, df_chain_counters[3]);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #47 from lucier at math dot purdue dot edu 2007-12-20 16:11
---
Subject: Re: Inordinate compile times on large routines
I don't know what's happening here, the patch doesn't apply; first I get
euler-13% patch zadeck2.patch
patching file df-problems.c
patch: malformed patch at line 8: df_chain_flags)df_chain-
local_flags)(FLAG))
and then after I join this line to the previous one (I think bugzilla
reformatted those lines), I get
euler-15% !pa
patch zadeck2.patch
patching file df-problems.c
Hunk #1 FAILED at 1855.
1 out of 2 hunks FAILED -- saving rejects to file df-problems.c.rej
euler-16% cat df-problems.c.rej
***
*** 1855,1867
#define df_chain_problem_p(FLAG) (((enum df_chain_flags)df_chain-
local_flags)(FLAG))
/* Create a du or ud chain from SRC to DST and link it into SRC. */
struct df_link *
df_chain_create (struct df_ref *src, struct df_ref *dst)
{
struct df_link *head = DF_REF_CHAIN (src);
- struct df_link *link = pool_alloc (df_chain-block_pool);;
DF_REF_CHAIN (src) = link;
link-next = head;
--- 1855,1877
#define df_chain_problem_p(FLAG) (((enum df_chain_flags)df_chain-
local_flags)(FLAG))
+ static long df_chain_counters[4];
+
/* Create a du or ud chain from SRC to DST and link it into SRC. */
struct df_link *
df_chain_create (struct df_ref *src, struct df_ref *dst)
{
struct df_link *head = DF_REF_CHAIN (src);
+ struct df_link *link = pool_alloc (df_chain-block_pool);
+ int index = 0;
+
+ if (!src-insn)
+ index += (src-type == DF_REF_REG_DEF) ? 2 : 1;
+ if (!dst-insn)
+ index += (dst-type == DF_REF_REG_DEF) ? 2 : 1;
+
+ df_chain_counters[index]++;
DF_REF_CHAIN (src) = link;
link-next = head;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-12-20 16:41 --- Another question: contrary to g77, we now have support for OpenMP. How about concurrency issues? Shall DTIME give the time since the last invokation from any thread, i.e. maintain a global storage, or the last invokation from the same thread, i.e. thread local storage? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 16:41:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug libstdc++/34538] New: combination of sstream, invalid_argument and -std=c++0x breaks valid code
#include sstream
#include stdexcept
int func()
{
std::string s;
throw std::invalid_argument( s );
}
g++-4.3.0 -std=c++0x test.cpp
test.cpp: In function 'int func()':
test.cpp:7: error: 'invalid_argument' cannot be used as a function
this code compiles only, if -std=c++0x is not given. If you just include
string instead of sstream, it also works with -std=c++0x, so it seems to be
related to the declarations in sstream, but i couldn't manage to dig deeper. I
tried to reduce the preprocessed source using delta/topformflat, but it kicked
out the declaration of invalid_argument giving me the same error.
Strangely using a smililar type like domain_error or out_of_range (they have
the same base-class and their only definition is the constructor) works too.
gcc version 4.3.0 20071213 (experimental) (GCC)
--
Summary: combination of sstream, invalid_argument and -std=c++0x
breaks valid code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34538
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #48 from zadeck at naturalbridge dot com 2007-12-20 17:28 --- Created an attachment (id=14801) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14801action=view) patch to count different types of def-use chains this patch replaces the one munged by bugzilla -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c++/34539] New: [4.3 Regression]: Extra libmudflap.c++ failures
Between revision 130941 and revision 131009, there are extra libmudflap failures: +FAIL: libmudflap.c++/fail24-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (test for excess errors) It happens on Linux/ia32, Linux/Intel64 and Linux/ia64. -- Summary: [4.3 Regression]: Extra libmudflap.c++ failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34539
[Bug c++/34539] [4.3 Regression]: Extra libmudflap.c++ failures
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 17:35 --- *** This bug has been marked as a duplicate of 34535 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34539
[Bug debug/34535] [4.3 Regression] FAIL: libmudflap.c++/fail24-frag.cxx ICE
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-20 17:35 --- *** Bug 34539 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34535
[Bug libstdc++/34498] FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test
--- Comment #4 from pcarlini at suse dot de 2007-12-20 17:39 --- This is already fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34498
[Bug libstdc++/34538] [DR 697] combination of sstream, invalid_argument and -std=c++0x breaks valid code
--- Comment #1 from pcarlini at suse dot de 2007-12-20 17:44 --- This is a known issue: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697 -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 17:44:14 date|| Summary|combination of sstream, |[DR 697] combination of |invalid_argument and - |sstream, invalid_argument |std=c++0x breaks valid code |and -std=c++0x breaks valid ||code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34538
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #2 from hjl at lucon dot org 2007-12-20 17:45 --- Created an attachment (id=14802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14802action=view) Dump files Starting program: /export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gcc/a.out Program received signal SIGSEGV, Segmentation fault. 0x4751 in main () at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_global_var.c:22 22 p[i].a = p[i].b + 1; (gdb) p/x $pc $4 = 0x4751 (gdb) disass 0x4740 0x4752 Dump of assembler code from 0x4740 to 0x4752: 0x4740 main+192: [MII] shladd r15=r16,2,r0 0x4741 main+193: adds r16=1,r16;; 0x4742 main+194: add r14=r33,r15 0x4750 main+208: [MMI] add r15=r8,r15;; 0x4751 main+209: ldfs f6=[r14] End of assembler dump. (gdb) p/x $r14 $5 = 0x5f60 (gdb) ldfs f6=[r14] loads memory at r14 into FP register f6. It looks that -fipa-struct-reorg miscompiles the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug tree-optimization/34458] [4.3 Regression] ICE in int_cst_value, at tree.c:8047 at -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |tree-optimization Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34458
[Bug middle-end/34467] [4.3 Regression] ICE in lookup_subvars_for_var, at tree-flow-inline.h:1586
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34467
[Bug target/34493] [4.2/4.3 Regression] ICE reload_cse_simplify_operands, at postreload.c:392 on powerpc with -funroll-loops
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34493
[Bug c++/34485] [4.1/4.2/4.3 regression] ICE with undefined type in template parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:05 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 18:05:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34485
[Bug c++/34486] [4.1/4.2/4.3 regression] ICE invalid using declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:05 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 18:05:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34486
[Bug c++/34487] [4.1/4.2/4.3 regression] ICE using class instead of typename
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:07 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 18:07:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34487
[Bug c++/34491] [4.1/4.2/4.3 regression] ICE invalid template specialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:07 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 18:07:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34491
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
-- 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=34525
[Bug libfortran/34530] [4.3 regression] namelist read broken when whitespace after namelist
-- 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=34530
[Bug fortran/34537] ICE or wrong code for TRANSFER of constant string to character
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 18:23:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #4 from kargl at gcc dot gnu dot org 2007-12-20 18:26 --- (In reply to comment #3) Another question: contrary to g77, we now have support for OpenMP. How about concurrency issues? Shall DTIME give the time since the last invokation from any thread, i.e. maintain a global storage, or the last invokation from the same thread, i.e. thread local storage? I think gfortran will need to handle it similar to how random_seed is done. See libgfortran/intrinsics/random.c. In fact, one could potentially import the code from random.c into dtime with only a minimum effort (famaous last words). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug libstdc++/34538] [DR 697] combination of sstream, invalid_argument and -std=c++0x breaks valid code
--- Comment #2 from rbuergel at web dot de 2007-12-20 18:30 --- (In reply to comment #1) This is a known issue: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697 Ooops. I only looked in the gcc bug database. Probably i should expand my research before filing a bug ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34538
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-12-20 18:35 --- I think gfortran will need to handle it similar to how random_seed is done. Using a mutex, yes, that's what I thought as well. Btw, CPU_TIME gives values per process and does not bother with threads. DTIME probably wants to do the same? While at it, a common time aquisition function for all three, CPU_TIME, DTIME and ETIME, would be useful. Currently, ETIME has an implementation separate from CPU_TIME -- but both use getrusage(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #49 from lucier at math dot purdue dot edu 2007-12-20 18:56 --- Subject: Re: Inordinate compile times on large routines I think this is the extra information you wanted: real - real = 163962912 real - art = 0 art - real = 0 art - art = 0 Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #6 from kargl at gcc dot gnu dot org 2007-12-20 19:39 --- (In reply to comment #5) I think gfortran will need to handle it similar to how random_seed is done. Using a mutex, yes, that's what I thought as well. Btw, CPU_TIME gives values per process and does not bother with threads. DTIME probably wants to do the same? I thought about this a little more. Because dtime() is provided for backwards compatibility with g77 and g77 did not (to my knowledge) support any kind of threading model, I would make it work under the assumption of a nonthreaded process. In the documentation, simply note that the behavior of dtime() is undefined (or processor-dependent) when used in a threaded process. Otherwise, I think you're going to run into strange race conditions and oddly reported timings. While at it, a common time aquisition function for all three, CPU_TIME, DTIME and ETIME, would be useful. Currently, ETIME has an implementation separate from CPU_TIME -- but both use getrusage(). It's been a long time since I looked at the code. But, yes, I would think one would want a single aquisition function with the intrinsics being simple wrappers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug target/34493] [4.2 Regression] ICE reload_cse_simplify_operands, at postreload.c:392 on powerpc with -funroll-loops
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-20 19:39 --- Yeah, works for me on the trunk too. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression] ICE|[4.2 Regression] ICE |reload_cse_simplify_operands|reload_cse_simplify_operands |, at postreload.c:392 on|, at postreload.c:392 on |powerpc with -funroll-loops |powerpc with -funroll-loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34493
[Bug tree-optimization/34448] [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
--- Comment #11 from jakub at gcc dot gnu dot org 2007-12-20 20:01 --- *** Bug 34467 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug middle-end/34467] [4.3 Regression] ICE in lookup_subvars_for_var, at tree-flow-inline.h:1586
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-20 20:01 --- This is a dup of PR34448, Aldy's latest patch fixes it as well. *** This bug has been marked as a duplicate of 34448 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34467
[Bug libgcj/34521] SSLEngine - Clone not supported (Null pointer) exception
--- Comment #3 from jarygrove at yahoo dot com 2007-12-20 20:32 --- Subject: Re: SSLEngine - Clone not supported (Null pointer) exception I tried and got the following output [Ljava.lang.String;@1f6af68 [Ljava.lang.String;@1f6af60 - Original Message From: csm at gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 18, 2007 12:08:52 PM Subject: [Bug libgcj/34521] SSLEngine - Clone not supported (Null pointer) exception --- Comment #2 from csm at gnu dot org 2007-12-18 18:08 --- Created an attachment (id=14790) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14790action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14790action=view) Test case Can you try running this test program in your setup? We should confirm first that this isn't a regression in GCJ -- based on your description, it looks like a 'clone()' call is failing on a String array, which should not happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521
[Bug libfortran/34540] New: cshift, eoshift, kind=1 and kind=2 arguments...
I really thought we had these figured out... $ cat shift-variations.f90 program main integer(kind=1) :: d1 integer(kind=2) :: d2 integer(kind=4) :: d4 integer(kind=8) :: d8 integer(kind=1), dimension(2) :: s1 integer(kind=2), dimension(2) :: s2 integer(kind=4), dimension(2) :: s4 integer(kind=8), dimension(2) :: s8 real, dimension(2,2) :: r data r /1.0, 2.0, 3.0, 4.0/ s1 = (/1, 1/) s2 = (/1, 1/) s4 = (/1, 1/) s8 = (/1, 1/) d1 = 1 d2 = 1 d4 = 1 d8 = 1 print *,eoshift(r,shift=s1,dim=d1) print *,eoshift(r,shift=s2,dim=d2) print *,eoshift(r,shift=s4,dim=d4) print *,eoshift(r,shift=s8,dim=d8) print *,cshift(r,shift=s1,dim=d1) print *,cshift(r,shift=s2,dim=d2) print *,cshift(r,shift=s4,dim=d4) print *,cshift(r,shift=s8,dim=d8) end program main $ gfortran shift-variations.f90 $ ./a.out 0.000 3.98764005E-34 1.26116862E-44 0.000 -2.73992191E-05 -2.85282731E-05 0.000 4.08616923E-38 2.000 0.000 4.000 0.000 2.000 0.000 4.000 0.000 Fortran runtime error: Argument 'DIM' is out of range in call to 'CSHIFT' $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20071216 (experimental) (GCC) -- Summary: cshift, eoshift, kind=1 and kind=2 arguments... Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug c++/34051] [4.3 regression] ICE in dependent_type_p with variadic templates
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-19 05:54:52 |2007-12-20 20:56:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug c++/34052] [4.3 regression] Trouble with variadic templates as template-template parameter
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-19 04:17:13 |2007-12-20 21:00:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug c++/34055] [4.3 regression] ICE with invalid specialization of variadic template
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 21:02:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
[Bug c++/34102] [4.3 regression] ICE with invalid inheritance of variadic templates
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-19 03:45:45 |2007-12-20 21:03:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-19 05:21:38 |2007-12-20 21:04:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug c++/34219] gcc doesn't accept const members of variadic templates as const
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-25 03:15:38 |2007-12-20 21:07:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34219
[Bug c++/34314] [4.3 Regression] ICE on invalid code (with variadic templates): tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in template_class_depth
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-12-02 21:10:03 |2007-12-20 21:08:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34314
[Bug c++/34399] [4.3 regression] ICE on invalid friend declaration of variadic template
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-12-08 23:08:12 |2007-12-20 21:09:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34399
[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 21:16:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #7 from kargl at gcc dot gnu dot org 2007-12-20 21:28 --- A quick scan of intrinsics.c shows that dtime() is treated as an alias to etime(). So, one needs to make dtime() a full-fledged intrinsic procedure. add_sym_1 (etime, GFC_ISYM_ETIME, NO_CLASS, ACTUAL_NO, BT_REAL, 4, GFC_STD_GNU, gfc_check_etime, NULL, NULL, x, BT_REAL, 4, REQUIRED); make_alias (dtime, GFC_STD_GNU); make_generic (etime, GFC_ISYM_ETIME, GFC_STD_GNU); Daniel, are you working on this PR? -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-12-20 21:39 --- one needs to make dtime() a full-fledged intrinsic procedure. This minute, I just realized the same ... Daniel, are you working on this PR? Sort of. Finished the library part. Btw, CPU_TIME has a fallback implementation using times(2). As times() returns the number of clock ticks that have elapsed since an arbitrary point in the past, it is IMO unsuitable to be used with CPU_TIME. CPU_TIME is supposed to return a value representing the elapsed CPU time in seconds [since start of the program]. Thus, I ditched this fallback for the common implementation. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-12-20 16:41:21 |2007-12-20 21:39:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug c++/34111] [4.3 Regression] new overload resolution error
--- Comment #5 from jason at gcc dot gnu dot org 2007-12-20 22:16 --- Subject: Bug 34111 Author: jason Date: Thu Dec 20 22:16:19 2007 New Revision: 131107 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131107 Log: PR c++/34111 * call.c (standard_conversion): Derived-to-base is considered a standard conversion. Added: trunk/gcc/testsuite/g++.dg/overload/arg5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2007-12-20 22:27 --- Subject: Re: DTIME returns total process time and not since last invocation On Thu, Dec 20, 2007 at 09:39:29PM -, dfranke at gcc dot gnu dot org wrote: Daniel, are you working on this PR? Sort of. Finished the library part. Btw, CPU_TIME has a fallback implementation using times(2). As times() returns the number of clock ticks that have elapsed since an arbitrary point in the past, it is IMO unsuitable to be used with CPU_TIME. CPU_TIME is supposed to return a value representing the elapsed CPU time in seconds [since start of the program]. Thus, I ditched this fallback for the common implementation. Actually, you don't need to remove the fallback because Niote 13.8 in the F95 standard makes it clear that the initialize time does not need to be referenced to zero. From Note 13.8: The start time is left imprecise because the purpose is to time sections of code, as in the example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-12-20 22:33 --- From Note 13.8: The start time is left imprecise because the purpose is to time sections of code, as in the example. Thanks for pointing it out. I'll re-add this fallback to CPU_TIME. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug c++/34541] New: ICE in template specialization using a typedef to an anonymous enum
templateclass _T2 struct X {
templateclass _U2 X(_U2 __y){}
};
template class T class Y{};
template class Yvoid {
typedef enum {} Z;
Y():z(), x(z) {}
Z z;
XZ x;
};
g++-4.3.0 -c test.cpp
test.cpp: In constructor 'Yvoid::Y()':
test.cpp:10: internal compiler error: Segmentation fault
if typedef enum {} Z; is replaced by enum Z {}, it compiles fine.
gcc-4.2.2 and 4.1.2 compile without problems
--
Summary: ICE in template specialization using a typedef to an
anonymous enum
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34541
[Bug c++/34541] ICE in template specialization using a typedef to an anonymous enum
--- Comment #1 from rbuergel at web dot de 2007-12-20 22:47 --- gcc version 4.3.0 20071213 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34541
[Bug c/34542] New: gcc.c-torture/compile/20071117-1.c fails on powerpc at -O0
The testcase gcc.c-torture/compile/20071117-1.c fails on both powerpc-apple-darwin* and powerpc64-unknown-linux-gnu at -O0. The failure on powerpc-apple-darwin9 appears as... Executing on host: /sw/src/fink.build/gcc43-4.2.999-20071219/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc43-4.2.999-20071219/darwin_objdir/gcc/ -O0 -w -fno-show-column -c -m32 -o 20071117-1.o /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c (timeout = 300) /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c: In function 'foo': /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:13: error: unrecognizable insn: (insn 29 28 30 3 /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:10 (set (mem/c:SI (mem/f/c/i:SI (plus:SI (reg/f:SI 1 15 virtual-stack-vars) (const_int 4 [0x4])) [0 p+0 S4 A32]) [0 S4 A8]) (reg:SI 134)) -1 (nil)) /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:13: internal compiler error: in extract_insn, at recog.c:1990 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c: In function 'foo': /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:13: error: unrecognizable insn: (insn 29 28 30 3 /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:10 (set (mem/c:SI (mem/f/c/i:SI (plus:SI (reg/f:SI 1 15 virtual-stack-vars) (const_int 4 [0x4])) [0 p+0 S4 A32]) [0 S4 A8]) (reg:SI 134)) -1 (nil)) /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:13: internal compiler error: in extract_insn, at recog.c:1990 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/compile/20071117-1.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/20071117-1.c -O0 (test for excess errors) Excess errors: /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:13: error: unrecognizable insn: (insn 29 28 30 3 /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:10 (set (mem/c:SI (mem/f/c/i:SI (plus:SI (reg/f:SI 1 15 virtual-stack-vars) (const_int 4 [0x4])) [0 p+0 S4 A32]) [0 S4 A8]) (reg:SI 134)) -1 (nil)) /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.c-torture/compile/20071117-1.c:13: internal compiler error: in extract_insn, at recog.c:1990 -- Summary: gcc.c-torture/compile/20071117-1.c fails on powerpc at - O0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34542
[Bug c/34542] gcc.c-torture/compile/20071117-1.c fails on powerpc at -O0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 22:55 --- *** This bug has been marked as a duplicate of 34393 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34542
[Bug target/34393] ICE: in extract_insn, at recog.c:1990
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-20 22:55 --- *** Bug 34542 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
[Bug c++/34111] [4.3 Regression] new overload resolution error
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-20 23:13 --- Can we close this now, or do you want to keep it around until you get core feedback? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #3 from hjl at lucon dot org 2007-12-21 00:25 --- I configured gcc with --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \ --enable-shared \ --enable-threads=posix \ --enable-haifa \ --enable-checking=assert \ --prefix=/usr/gcc-4.3 \ --with-local-prefix=/usr/local -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include iostream
--- Comment #8 from dje at gcc dot gnu dot org 2007-12-21 00:29 --- The issue is whether to default G++ to _LARGE_FILES, as is done for Fortran, and perform all libstdc++ I/O as 64-bit operations, which will affect performance. Not everyone may want or need large I/O. There is no way to give users control over this without imposing it so G++, G++ headers, and libstdc++ all are self-consistent. The other alternative is another multilib, but there alredy are too many variants. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-21 00:29:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug c/34543] New: gcc.dg/out-of-bounds-1.c fails on -mstrict-align for powerpc-apple-darwin
The gcc.dg/out-of-bounds-1.c testcase fails on powerpc-apple-darwin9 with the
error...
Executing on host:
/sw/src/fink.build/gcc43-4.2.999-20071219/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071219
/darwin_objdir/gcc/
/sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.dg/out-of-bounds-1.c
-O -g -
mstrict-align -fno-show-column -S -m32 -o out-of-bounds-1.s(timeout = 300)
cc1: error: unrecognized command line option -mstrict-align
compiler exited with status 1
output is:
cc1: error: unrecognized command line option -mstrict-align
FAIL: gcc.dg/out-of-bounds-1.c (test for excess errors)
Excess errors:
cc1: error: unrecognized command line option -mstrict-align
The dg-options line...
/* { dg-options -O -g -mstrict-align { target powerpc*-*-* } } */
...needs to be re-written to exclude power-*-darwin* from using -mstrict-align.
--
Summary: gcc.dg/out-of-bounds-1.c fails on -mstrict-align for
powerpc-apple-darwin
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34543
[Bug testsuite/34543] gcc.dg/out-of-bounds-1.c fails on -mstrict-align for powerpc-apple-darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-21 00:51 --- This testcase should be running for powerpc*-*-linux* and powerpc*-*-elf* targets. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34543
[Bug testsuite/34543] gcc.dg/out-of-bounds-1.c fails on -mstrict-align for powerpc-apple-darwin
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-12-21 00:54 --- It does compile fine on powerpc-apple-darwin9 without the -mstrict-align. FYI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34543
[Bug boehm-gc/34544] New: pthread_default_stacksize_np failed.
make[4]: Entering directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/boehm-gc ' pthread_default_stacksize_np failed. /bin/sh[9]: 407 Bus error(coredump) FAIL: gctest I believe that the fail is expected. -- Summary: pthread_default_stacksize_np failed. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-12-21 03:00 --- It works fine on ppc64-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34482
[Bug bootstrap/34003] [4.1 Regression] gcc trunk unable to bootstrap itself; Unsatisfied symbols: ggc_free
--- Comment #41 from danglin at gcc dot gnu dot org 2007-12-21 03:06 --- Subject: Bug 34003 Author: danglin Date: Fri Dec 21 03:05:43 2007 New Revision: 131114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131114 Log: PR bootstrap/34003 * c-decl.c (merge_decls): Copy RTL from olddecl to newdecl. * config/pa/pa.c (pa_encode_section_info): If !first, preserve SYMBOL_FLAG_REFERENCED flag. * gcc.dg/pr34003-1.c: New test. * gcc.dg/pr34003-2.c: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr34003-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr34003-2.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-decl.c branches/gcc-4_1-branch/gcc/config/pa/pa.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
[Bug bootstrap/34003] [4.1 Regression] gcc trunk unable to bootstrap itself; Unsatisfied symbols: ggc_free
--- Comment #42 from danglin at gcc dot gnu dot org 2007-12-21 03:07 --- Fixed on all active branches. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-12-21 03:13 --- This is a regression. The test case is OK with 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|cshift, eoshift, kind=1 and |[4.3 Regression] cshift, |kind=2 arguments... |eoshift, kind=1 and kind=2 ||arguments... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include iostream
--- Comment #9 from bugzilla-gcc at thewrittenword dot com 2007-12-21 03:59 --- (In reply to comment #8) The issue is whether to default G++ to _LARGE_FILES, as is done for Fortran, and perform all libstdc++ I/O as 64-bit operations, which will affect performance. Not everyone may want or need large I/O. There is no way to give users control over this without imposing it so G++, G++ headers, and libstdc++ all are self-consistent. The other alternative is another multilib, but there alredy are too many variants. Why is this? -D_LARGE_FILES simply enables LFS. xlC works with and without -D_LARGE_FILES. Shouldn't G++ work as effectively as xlC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug c++/34111] [4.3 Regression] new overload resolution error
--- Comment #7 from jason at gcc dot gnu dot org 2007-12-21 04:10 --- We can close it. The core feedback I'm interested in is about the testcase for Bug 17431, not this one. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
[Bug fortran/34545] New: ICE when compiling Fortran 95 code
Overview Description: ICE when compiling source code. Steps to Reproduce: Download code from http://www.k9shrink.com/kmeans.f90 and compile with gfortran -Wall -v -save-temps kmeans.f90 What happens is ICE with segmentation fault. Actual Results: ICE Expected Results: compilation or list of warnings and errors encountered. Build Date Platform: 20070813, Windows Vista Additional Information: Platform is Windows Vista. gcc version 4.3.0 20070813 (experimental) using gfortran Source is available from http://www.k9shrink.com/kmeans.f90 I enter following compile command and get following response: G:\fortran\KMeansClustgfortran -v -Wall -save-temps kmeans.f90 Driving: gfortran -v -Wall -save-temps kmeans.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld - -with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i386-pc-mingw32 --enable-libgomp Thread model: win32 gcc version 4.3.0 20070813 (experimental) f951 kmeans.f90 -quiet -dumpbase kmeans.f90 -mtune=i386 -auxbase kmeans -Wall -version -fintrinsic-modules-path finclude -o kmeans. s GNU F95 version 4.3.0 20070813 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.3.0 20070813 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 kmeans.f90: In function 'MAIN__': kmeans.f90:2054: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Code compiles and runs with Lahey/Fujitsu LF95 Version 7.1 Win32 compiler (although gfortran finds valid problems whilst LF95 does not, so this may not mean much). Pardon if this is not best format, this is my first submission. -- Summary: ICE when compiling Fortran 95 code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jon_d_r at msn dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #1 from jon_d_r at msn dot com 2007-12-21 04:50 --- Created an attachment (id=14803) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14803action=view) Source code that causes ICE This is the code that caused the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #2 from jon_d_r at msn dot com 2007-12-21 04:57 --- Downloaded and installed later version of gfortran. GNU F95 (GCC) version 4.3.0 20071130 (experimental) [trunk revision 130537] I still get ICE: G:\fortran\KMeansClustgfortran -v -Wall -save-temps kmeans.f90 Driving: gfortran -v -Wall -save-temps kmeans.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld - -with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i386-pc-mingw32 --enable-libgomp - -disable-shared Thread model: win32 gcc version 4.3.0 20071130 (experimental) [trunk revision 130537] (GCC) COLLECT_GCC_OPTIONS='-v' '-Wall' '-save-temps' '-mtune=i386' c:/program files/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe kmeans.f90 -quiet -dumpbase kmeans.f90 -mtune=i386 -aux base kmeans -Wall -version -fintrinsic-modules-path c:/program files/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o kmean s.s GNU F95 (GCC) version 4.3.0 20071130 (experimental) [trunk revision 130537] (i386-pc-mingw32) compiled by GNU C version 4.3.0 20071130 (experimental) [trunk revision 130537], GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 kmeans.f90: In function 'kmeans_driver': kmeans.f90:2054: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- jon_d_r at msn dot com changed: What|Removed |Added CC||jon_d_r at msn dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #3 from jv244 at cam dot ac dot uk 2007-12-21 06:09 --- code compiles fine with NAG and g95, the line at the segfault looks OK. -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-21 06:09:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #4 from kargl at gcc dot gnu dot org 2007-12-21 06:14 --- Here's a reduced testcase. module const_mod implicit none integer, parameter :: mp = selected_real_kind(15,300) end module const_mod module blk1_mod implicit none integer :: numclusters = 2 end module blk1_mod module kmeans_aux implicit none contains function get_nfirst( ) result(fnres) use const_mod, only: mp use blk1_mod, only: numclusters implicit none real(mp) :: fnres(numclusters) end function get_nfirst end module kmeans_aux program kmeans_driver use blk1_mod use kmeans_aux implicit none integer, allocatable :: nfirst(:) allocate(nfirst(1:numclusters)) nfirst(1:numclusters) = get_nfirst( ) end program kmeans_driver -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug c++/29363] [4.2/4.3 regression] ICE throwing undeclared object
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-21 07:28 --- Lee, Patch was rejected: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00976.html Was it your plan to give it another try from behind the drawing board? :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug c++/27078] [4.1/4.2/4.3 Regression] Duplicate error message for ambiguous enum
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-21 07:30 --- Ollie, ping? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27078
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #5 from burnus at gcc dot gnu dot org 2007-12-21 07:39 --- valgrind: ==6521== Invalid read of size 1 ==6521==at 0x49C7D0: gfc_get_symbol_decl (trans-decl.c:899) ==6521==by 0x4A47DC: gfc_conv_variable (trans-expr.c:424) ==6521==by 0x4A7079: gfc_apply_interface_mapping (trans-expr.c:1949) ==6521==by 0x486BFA: gfc_set_loop_bounds_from_array_spec (trans-array.c:474) ==6521==by 0x4A16C3: gfc_conv_function_call (trans-expr.c:2633) ==6521==by 0x4A2398: gfc_conv_function_expr (trans-expr.c:3050) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.1.3 4.2.2 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
