[Bug fortran/34660] elemental and dummy procedure

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-01-05 08:09 ---
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00165.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34660

[Bug fortran/34654] no unformatted on internal file

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-01-05 08:13 ---
Fails for '*', e.g.:

gfortran.dg/arrayio_10.f90:8.7:

  read(arraydata,*,iostat=iostat)tmp
  1
Error: Unformatted I/O is not possible on an internal file at (1)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34654

[Bug fortran/34654] no unformatted on internal file

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-01-05 09:24 ---
http://gcc.gnu.org/ml/fortran/2008-01/msg00040.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34654

[Bug tree-optimization/34649] redundant if expression in find_conditional_asserts

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-01-05 09:32 ---
The patch was committed to SVN.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34649

[Bug tree-optimization/34618] [4.3 regression] ICE with -fmudflap and vectorization

[jakub at gcc dot gnu dot org]

-- 

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/2008-
   ||01/msg00171.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-01 10:02:49 |2008-01-05 09:48:36
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34618

[Bug tree-optimization/34649] redundant if expression in find_conditional_asserts

[zhouyi04 at ios dot cn]

--- Comment #4 from zhouyi04 at ios dot cn  2008-01-05 09:54 ---
Subject: Re:  redundant if expression in
 find_conditional_asserts

Thanks, 
I think I am now able to follow 
http://gcc.gnu.org/contribute.html#testing
Sincerely yours
Zhouyi Zhou


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34649

[Bug libstdc++/34680] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti

[pcarlini at suse dot de]

--- Comment #8 from pcarlini at suse dot de  2008-01-05 10:23 ---
(In reply to comment #6)
> Agreed. We should remove the offending patch set from 4.2. It's been too
> troublesome and we can't do this kind of compile-behavior change on a minor
> update to a stable release series.

Agreed.

> Oh well.
> 
> Probably what needs to happen on mainline is 
> 
> -fexceptions and __EXCEPTIONS 
> 
> should be used to model something like
> 
> -frtti and __RTTI
> 
> Then macro solutions are possible in the library.
> 
> Or, we could change mainline cc1plus to silently convert dynamic_cast to
> static_cast when -fno-rtti. I would actually prefer this solution. 

Yes, I would also like the latter solution, a lot. But whereas I could
reasonably quickly implement myself the latter, I'm not at all sure about the
former and I'm not even sure the C++ front-end maintainers agree with the idea
itself :( I'm adding Mark and Jason in CC, to have feedback, also about the
good point you are raising in the next message.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||mark at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680

[Bug libstdc++/34680] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti

[pcarlini at suse dot de]

--- Comment #9 from pcarlini at suse dot de  2008-01-05 10:25 ---
(In reply to comment #8)
>  But whereas I could
> reasonably quickly implement myself the latter, I'm not at all sure about the
> former

Of course read it the other way round, sorry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680

[Bug libstdc++/34680] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-05 10:27:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680

[Bug target/34673] ICE in extract_insn, at recog.c:1990

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-01-05 10:59 ---
(In reply to comment #3)
> I don't see how we can handle ne:SF anywhere.

(define_insn "sse_maskcmpsf3"
  [(set (match_operand:SF 0 "register_operand" "=x")
(match_operator:SF 3 "sse_comparison_operator"
[(match_operand:SF 1 "register_operand" "0")
 (match_operand:SF 2 "nonimmediate_operand" "xm")]))]

It is just the issue with reversed operands:

Index: i386.c
===
--- i386.c  (revision 131332)
+++ i386.c  (working copy)
@@ -24239,7 +24239,7 @@

   /* Compare a to zero.  */
   emit_insn (gen_rtx_SET (VOIDmode, mask,
- gen_rtx_NE (mode, a, zero)));
+ gen_rtx_NE (mode, zero, a)));

   /* x0 = 1./sqrt(a) estimate */
   emit_insn (gen_rtx_SET (VOIDmode, x0,


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-04 13:59:31 |2008-01-05 10:59:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34673

Re: SSE regression

[Uros Bizjak]

Hello!


I have a piece of code that runs ~70% slower on a Xeon CPU with
SSE enable than with plain 387.


Please enter the bugreport in our Bugzilla system, following 
instructions at http://gcc.gnu.org/bugs.html


Uros.

[Bug libstdc++/30127] std::has_facet returns true for not installed derived facets

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2008-01-05 11:05 ---
Subject: Bug 30127

Author: paolo
Date: Sat Jan  5 11:04:43 2008
New Revision: 131334

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131334
Log:
2008-01-05  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/34680

Revert:
2007-12-17  Jonathan Wakely  <[EMAIL PROTECTED]>
* include/bits/locale_facets.tcc (has_facet, use_facet): Simplify
RTTI checks.

2007-12-14  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/30127
PR libstdc++/34449
* include/bits/locale_facets.tcc (use_facet): Check facet hierarchy.
(has_facet): Same.
* testsuite/22_locale/global_templates/user_facet_hierarchies.cc: New.
* testsuite/22_locale/global_templates/
standard_facet_hierarchies.cc: New.

Removed:
   
branches/gcc-4_2-branch/libstdc++-v3/testsuite/22_locale/global_templates/standard_facet_hierarchies.cc
   
branches/gcc-4_2-branch/libstdc++-v3/testsuite/22_locale/global_templates/user_facet_hierarchies.cc
Modified:
branches/gcc-4_2-branch/libstdc++-v3/ChangeLog
branches/gcc-4_2-branch/libstdc++-v3/include/bits/locale_facets.tcc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30127

[Bug libstdc++/34680] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti

[paolo at gcc dot gnu dot org]

--- Comment #10 from paolo at gcc dot gnu dot org  2008-01-05 11:05 ---
Subject: Bug 34680

Author: paolo
Date: Sat Jan  5 11:04:43 2008
New Revision: 131334

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131334
Log:
2008-01-05  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/34680

Revert:
2007-12-17  Jonathan Wakely  <[EMAIL PROTECTED]>
* include/bits/locale_facets.tcc (has_facet, use_facet): Simplify
RTTI checks.

2007-12-14  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/30127
PR libstdc++/34449
* include/bits/locale_facets.tcc (use_facet): Check facet hierarchy.
(has_facet): Same.
* testsuite/22_locale/global_templates/user_facet_hierarchies.cc: New.
* testsuite/22_locale/global_templates/
standard_facet_hierarchies.cc: New.

Removed:
   
branches/gcc-4_2-branch/libstdc++-v3/testsuite/22_locale/global_templates/standard_facet_hierarchies.cc
   
branches/gcc-4_2-branch/libstdc++-v3/testsuite/22_locale/global_templates/user_facet_hierarchies.cc
Modified:
branches/gcc-4_2-branch/libstdc++-v3/ChangeLog
branches/gcc-4_2-branch/libstdc++-v3/include/bits/locale_facets.tcc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680

[Bug libstdc++/34449] use_facet(locale::classic()) returns true

[paolo at gcc dot gnu dot org]

--- Comment #10 from paolo at gcc dot gnu dot org  2008-01-05 11:05 ---
Subject: Bug 34449

Author: paolo
Date: Sat Jan  5 11:04:43 2008
New Revision: 131334

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131334
Log:
2008-01-05  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/34680

Revert:
2007-12-17  Jonathan Wakely  <[EMAIL PROTECTED]>
* include/bits/locale_facets.tcc (has_facet, use_facet): Simplify
RTTI checks.

2007-12-14  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/30127
PR libstdc++/34449
* include/bits/locale_facets.tcc (use_facet): Check facet hierarchy.
(has_facet): Same.
* testsuite/22_locale/global_templates/user_facet_hierarchies.cc: New.
* testsuite/22_locale/global_templates/
standard_facet_hierarchies.cc: New.

Removed:
   
branches/gcc-4_2-branch/libstdc++-v3/testsuite/22_locale/global_templates/standard_facet_hierarchies.cc
   
branches/gcc-4_2-branch/libstdc++-v3/testsuite/22_locale/global_templates/user_facet_hierarchies.cc
Modified:
branches/gcc-4_2-branch/libstdc++-v3/ChangeLog
branches/gcc-4_2-branch/libstdc++-v3/include/bits/locale_facets.tcc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449

[Bug libstdc++/34449] use_facet(locale::classic()) returns true

[pcarlini at suse dot de]

--- Comment #11 from pcarlini at suse dot de  2008-01-05 11:06 ---
Fixed for 4.3.0 only, in the branch the patch has been reverted.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

   Target Milestone|4.2.3   |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449

[Bug tree-optimization/34649] redundant if expression in find_conditional_asserts

[zhouyi04 at ios dot cn]

--- Comment #5 from zhouyi04 at ios dot cn  2008-01-05 11:15 ---
from svn update, it is fixed.
make bootstrap OK


-- 

zhouyi04 at ios dot cn changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34649

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-05 11:19 ---
Sorry, -frounding-math does not help for this case - it assumes the _same_
rounding mode is in effect everywhere, but doesn't assume it is
round-to-nearest.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-05 11:19:52
   date||
Summary|Optimization generates  |Optimization generates
   |incorrect code with -   |incorrect code with -
   |frounding-math option   |frounding-math option
   ||(#pragma STDC FENV_ACCESS
   ||not implemented)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

[Bug tree-optimization/34679] [4.3 Regression] ICE: tree check: expected integer_type, have enumeral_type in host_integerp, at tree.c:4949 (predictive commoning)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-01-05 11:25 ---
#2  0x00b09925 in host_integerp (t=0x2b817cd15b70, pos=0)
at /space/rguenther/src/svn/trunk/gcc/tree.c:4949
#3  0x00686e97 in fold_plusminus_mult_expr (code=PLUS_EXPR, 
type=0x2b817c26f000, arg0=0x2b817cdf36c0, arg1=0x2b817c25d570)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:7402
...
#12 0x00caeb7e in chrec_fold_plus_1 (code=PLUS_EXPR, 
type=0x2b817c26f000, op0=0x2b817ce07700, op1=0x2b817cc7b630)
at /space/rguenther/src/svn/trunk/gcc/tree-chrec.c:323
...
#19 0x00952f5d in analyze_scalar_evolution_in_loop (
wrto_loop=0x2b817cc545a0, use_loop=0x2b817cc545a0, version=0x2b817ce07100, 
folded_casts=0x7fff2e8a6f3f "")
at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1854
#20 0x009579e0 in simple_iv (loop=0x2b817cc545a0, stmt=0x2b817d15b9f0, 
op=0x2b817ce07100, iv=0x7fff2e8a7030, allow_nonconstant_step=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:2663
#21 0x008bd379 in dr_analyze_innermost (dr=0x12266d0)
at /space/rguenther/src/svn/trunk/gcc/tree-data-ref.c:683
#22 0x008bf1eb in create_data_ref (nest=0x2b817cc545a0, 
memref=0x2b817d5335a0, stmt=0x2b817d15b9f0, is_read=1 '\001')
at /space/rguenther/src/svn/trunk/gcc/tree-data-ref.c:841
#23 0x008ce048 in find_data_references_in_stmt (nest=0x2b817cc545a0, 
stmt=0x2b817d15b9f0, datarefs=0x7fff2e8a72f8)
at /space/rguenther/src/svn/trunk/gcc/tree-data-ref.c:4026
#24 0x008ce434 in find_data_references_in_loop (loop=0x2b817cc545a0, 
datarefs=0x7fff2e8a72f8)
at /space/rguenther/src/svn/trunk/gcc/tree-data-ref.c:4071
#25 0x008ce9b3 in compute_data_dependences_for_loop (
loop=0x2b817cc545a0, compute_self_and_read_read_dependences=1 '\001', 
datarefs=0x7fff2e8a72f8, dependence_relations=0x7fff2e8a72f0)
at /space/rguenther/src/svn/trunk/gcc/tree-data-ref.c:4148
#26 0x0092e23a in tree_predictive_commoning_loop (loop=0x2b817cc545a0)
at /space/rguenther/src/svn/trunk/gcc/tree-predcom.c:2496

reproducible with a cross, -fno-predictive-commoning is a workaround.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org, spop at gcc dot gnu dot
   ||org
  Component|middle-end  |tree-optimization
Summary|[4.3 Regression] ICE: tree  |[4.3 Regression] ICE: tree
   |check: expected |check: expected
   |integer_type, have  |integer_type, have
   |enumeral_type in|enumeral_type in
   |host_integerp, at   |host_integerp, at
   |tree.c:4949 |tree.c:4949 (predictive
   ||commoning)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34679

[Bug libstdc++/30127] std::has_facet returns true for not installed derived facets

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2008-01-05 11:05 ---
Fixed for 4.3.0 only, in the branch the patch has been reverted.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

   Target Milestone|4.2.3   |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30127

[Bug libfortran/34670] bounds checking for array intrinsics

[tkoenig at netcologne dot de]

--- Comment #2 from tkoenig at netcologne dot de  2008-01-05 11:48 ---
Subject: Re:  bounds checking for array intrinsics


Hi Jerry,

> Do we want the overhead of bounds checking at run time on all these 
> intrinsics?

In the case of no bounds checking, it's a single if statement.

>  Is there a way to do it without the overhead?

We could duplicate every intrinsic array function, one version with
bounds checking and one without, then call the appropriate function.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670

[Bug target/34673] ICE in extract_insn, at recog.c:1990

[uros at gcc dot gnu dot org]

--- Comment #6 from uros at gcc dot gnu dot org  2008-01-05 11:53 ---
Subject: Bug 34673

Author: uros
Date: Sat Jan  5 11:52:39 2008
New Revision: 131335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131335
Log:
PR target/34673
* config/i386/i386.c (ix86_emit_swsqrtsf): Swap input operands
in the call to gen_rtx_NE.  Remove unneeded VECTOR_MODE_P check.
Update copyright year.

* config/i386/i386.md (rsqrtsf2): Enable for TARGET_SSE_MATH.
Update copyright year.
* config/i386/sse.md (rsqrtv4sf2): Ditto. Unconditionally expand
using NR fixup.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34673

[Bug tree-optimization/34618] [4.3 regression] ICE with -fmudflap and vectorization

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-01-05 12:07 ---
Subject: Bug 34618

Author: jakub
Date: Sat Jan  5 12:06:54 2008
New Revision: 131336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131336
Log:
PR tree-optimization/34618
* tree-outof-ssa.c (create_temp): Copy over DECL_GIMPLE_REG_P
flag from T.

* testsuite/libmudflap.c/pass62-frag.c: New test.

Added:
trunk/libmudflap/testsuite/libmudflap.c/pass62-frag.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-outof-ssa.c
trunk/libmudflap/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34618

[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-01-05 12:08 
---
(In reply to comment #6)
> Or, we could change mainline cc1plus to silently convert dynamic_cast to
> static_cast when -fno-rtti. I would actually prefer this solution. 

No because this was just fixed to be an error for 4.2.0, see PR 10891.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680

[Bug tree-optimization/34618] [4.3 regression] ICE with -fmudflap and vectorization

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-01-05 12:10 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34618

[Bug target/34673] ICE in extract_insn, at recog.c:1990

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2008-01-05 13:03 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34673

[Bug libfortran/34671] any(kind=1) and all(kind=1)

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-01-05 13:04 ---
Using GFOR_POINTER_TO_L1 for writing in "any" and "all" isn't
a good idea (it would lead to undefined bytes in the target
array).  I'll leave those alone and just add the corresponding
_l1 and _l2 functions.

For "count", we can at least eliminate the _l4, _l8 and _l16 versions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34671

[Bug c/12245] [4.0/4.1/4.2/4.3 regression] Uses lots of memory when compiling large initialized arrays

[rguenth at gcc dot gnu dot org]

--- Comment #32 from rguenth at gcc dot gnu dot org  2008-01-05 14:07 
---
The difference between using gcc and g++ for the testcase seems to be gone on
the trunk, where gcc peaks at 480MB and g++ at 530MB.  For 4.1 g++ used 780MB.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|3.4.3 4.0.0 |3.3.3 3.4.3 4.0.0 4.3.0
   Last reconfirmed|2006-09-03 21:41:14 |2008-01-05 14:07:50
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245

[Bug fortran/34665] Cannot pass scalar to array argument 'a'

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-01-05 14:57 ---
(In reply to comment #3)
> > We catch this with an explicit interface, but we
> > should still check for occurrence in the
> > same source code.
> 
> I do not understand this part. 

Ooops, you're correct.  Yes, we should catch this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34665

[Bug libfortran/34670] bounds checking for array intrinsics

[tkoenig at gcc dot gnu dot org]

-- 

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 |2008-01-05 15:25:19
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670

[Bug fortran/34676] [4.3 Regression] IO error delayed

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-01-05 16:01 
---
Subject: Bug 34676

Author: jvdelisle
Date: Sat Jan  5 16:00:40 2008
New Revision: 131337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131337
Log:
2008-01-05  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/34676
* io/list_read.c (next_char): Only save the EOF condition for later if
advance="no".

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34676

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[merkert at comcast dot net]

--- Comment #2 from merkert at comcast dot net  2008-01-05 15:38 ---
Ok, so how then would one accomplish this in std c without resorting to asm? I
still assume the original code is correct even though the rounding-math doesn't
do what I wanted.

At any rate, I played a little with it and there was hint in the asm manual how
to do it. This seems to work for me, but I'm not sure I'm using the constraints
as efficiently as possible:

#include 

inline void reload(double* x)
{
  asm volatile ("" : "=m"(x) );
}

void xdiv (double x, double y, double* lo, double* hi)
{
  #pragma STDC FENV_ACCESS ON
  fesetround(FE_DOWNWARD);
  *lo = x/y;

  reload(&y);

  fesetround(FE_UPWARD);
  *hi = x/y;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

[Bug fortran/34567] module name without a module

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2008-01-05 16:17 ---
This has been fixed in r131124 by PaulT (without reference to the PR in the
ChangeLog). Can we close this?


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org, pault at gcc dot gnu
   ||dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567

[Bug fortran/34676] [4.3 Regression] IO error delayed

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-01-05 16:12 
---
Subject: Bug 34676

Author: jvdelisle
Date: Sat Jan  5 16:12:00 2008
New Revision: 131338

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131338
Log:
2008-01-05  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/34676
* gfortran.dg/list_read_8.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/list_read_8.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34676

[Bug fortran/34567] module name without a module

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2008-01-05 16:47 ---
(In reply to comment #4)

If you look, the patch preceeded the PR.  Toon posted the problem on the list,
promising to develop this testcase. This he duly did.  Please keep it open
another few days; I'll clean up testcases, if needs be, and so on.

Thanks for the reminder, Daniel.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2008-01-05 17:07 ---
Subject: Re:  Optimization generates incorrect code
 with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote:

> Sorry, -frounding-math does not help for this case - it assumes the _same_
> rounding mode is in effect everywhere, but doesn't assume it is
> round-to-nearest.

To be clear: this is a bug in the present implementation of 
-frounding-math - it *should* disable all the assumptions of same rounding 
mode (unless it can prove that no function changing the rounding mode is 
called between the two places where it assumes the same mode), but, as 
documented in the manual, it's not yet fully implemented.

#   This option is experimental and does not currently guarantee to
#   disable all GCC optimizations that are affected by rounding mode.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

[Bug fortran/34676] [4.3 Regression] IO error delayed

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-01-05 17:03 
---
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34676

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-05 18:24 ---
I wouldn't read the language this way.  Because that will forcefully disable
all redundancy removing optimizations (which is what happens in this testcase).
What it currently guards is expression rewriting that changes the outcome if
a rounding mode different than round-to-nearest is used.

The finer-grained control the documentation mentions should not be globbed
to -frounding-math IMHO.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

[Bug fortran/34681] New: SAVEd derived type with allocatable components causes ICE

[pault at gcc dot gnu dot org]

The following segfaults on the second call to mah because the allocatable
components are automatically deallocated.  I have yet to check the F2003
standard but this logically makes no sense.  It comes about because t.data is
NULLED on entry to mah

program boh
  !
  call mah (0)
  call mah (1)
  call mah (2)
  !
end program boh
!
subroutine mah (i)
  !
  integer, intent(in) :: i
  !
  type mix_type
 real(8), allocatable :: a(:)
 complex(8), allocatable :: b(:)
  end type mix_type
  type(mix_type), allocatable, save :: t(:)
  integer :: j, n=1024
  !
  if (i==0) then
 allocate (t(1))
 allocate (t(1)%a(n))
 allocate (t(1)%b(n))
 do j=1,n
t(1)%a(j) = j
t(1)%b(j) = n-j
 end do
  end if
  c = sum( t(1)%a(:) ) + sum( t(1)%b(:) )
  print *, 'c=',c
  if ( i==2) then
 deallocate (t(1)%b)
 deallocate (t(1)%a)
 deallocate (t)
  end if
end subroutine mah

Posted to the list by F-X COudert

http://gcc.gnu.org/ml/fortran/2008-01/msg00044.html


-- 
   Summary: SAVEd derived type with allocatable components causes
ICE
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34681

[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c

[andreast at gcc dot gnu dot org]

--- Comment #17 from andreast at gcc dot gnu dot org  2008-01-05 20:50 
---
Subject: Bug 32843

Author: andreast
Date: Sat Jan  5 20:49:41 2008
New Revision: 131343

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131343
Log:
2008-01-05  Andreas Tobler  <[EMAIL PROTECTED]>

PR testsuite/32843
* src/x86/ffi.c (ffi_prep_cif_machdep): Add code for
signed/unsigned int8/16 for X86_DARWIN.
Updated copyright info.
Handle one and two byte structs with special cif->flags.
* src/x86/ffitarget.h: Add special types for one and two byte structs.
Updated copyright info.
* src/x86/darwin.S (ffi_call_SYSV): Rewrite to use a jump table like
sysv.S
Remove code to pop args from the stack after call.
Special-case signed/unsigned for int8/16, one and two byte structs.
(ffi_closure_raw_SYSV): Handle FFI_TYPE_UINT8,
FFI_TYPE_SINT8, FFI_TYPE_UINT16, FFI_TYPE_SINT16, FFI_TYPE_UINT32,
FFI_TYPE_SINT32.
Updated copyright info.

Modified:
trunk/libffi/ChangeLog
trunk/libffi/src/x86/darwin.S
trunk/libffi/src/x86/ffi.c
trunk/libffi/src/x86/ffitarget.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843

[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...

[jvdelisle at gcc dot gnu dot org]

--- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-01-05 21:00 
---
I think I have a patch for this. Testing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-21 21:07:37 |2008-01-05 21:00:04
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540

[Bug c/34682] 70% slowdown with SSE enabled

[rootkit85 at yahoo dot it]

--- Comment #1 from rootkit85 at yahoo dot it  2008-01-05 21:31 ---
Created an attachment (id=14882)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14882&action=view)
the source


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682

[Bug c/34682] 70% slowdown with SSE enabled

[rootkit85 at yahoo dot it]

--- Comment #2 from rootkit85 at yahoo dot it  2008-01-05 21:31 ---
Created an attachment (id=14883)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14883&action=view)
the source compiled with -mfpmath=387


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682

[Bug c/34682] 70% slowdown with SSE enabled

[rootkit85 at yahoo dot it]

--- Comment #3 from rootkit85 at yahoo dot it  2008-01-05 21:32 ---
Created an attachment (id=14884)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14884&action=view)
the source compiled with -mfpmath=sse


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682

[Bug c/34682] New: 70% slowdown with SSE enabled

[rootkit85 at yahoo dot it]

I have a piece of code that runs 70% slower with SSE enabled than with plain
387 on a Dual CPU Xeon system.
I'm not an optimization fanatic, but since -mfpmath=sse is enabled by default
on amd64 this could cause huge performance losses while making amd64 binaries
on this CPU

The runlog is:

[EMAIL PROTECTED] ~]$ uname -a
FreeBSD enc1 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007  
  [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP  
[EMAIL PROTECTED] ~]$ gcc42 -v
Using built-in specs.
Target: i386-portbld-freebsd6.2
Configured with: ./..//gcc-4.2-20071024/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
--program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.3
--with-gxx-include-dir=/usr/local/lib/gcc-4.2.3/include/c++/ --disable-rpath
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc42
i386-portbld-freebsd6.2
Thread model: posix
gcc version 4.2.3 20071024 (prerelease)
[EMAIL PROTECTED] ~]$ gcc42 ssucks.c -O2 -march=prescott -o ssucks-387
[EMAIL PROTECTED] ~]$ gcc42 ssucks.c -O2 -march=prescott -o ssucks-sse 
-mfpmath=sse
[EMAIL PROTECTED] ~]$ ssucks-387 ; ssucks-sse

   FLOPS C Program (Double Precision), V2.0 18 Dec 1992

   Module ErrorRunTime  MFLOPS
(usec)
 1  4.0146e-13  0.0147953.0052
 2 -1.4166e-13  0.0061   1149.6845

   FLOPS C Program (Double Precision), V2.0 18 Dec 1992

   Module ErrorRunTime  MFLOPS
(usec)
 1  4.0146e-13  0.0146960.7945
 2 -1.4166e-13  0.0281249.3171
[EMAIL PROTECTED] ~]$

1149.6845 vs 249.3171: a ~78% slowdown by just enabling sse

I have source, assembled files and runlog online here:
http://teknoraver.campuslife.it/software/gcc-sse/

Cheers,
Matteo Croce


-- 
   Summary: 70% slowdown with SSE enabled
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rootkit85 at yahoo dot it


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682

[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti

[pcarlini at suse dot de]

--- Comment #12 from pcarlini at suse dot de  2008-01-05 23:13 ---
I see... Therefore, apparently we don't have many options...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680

[Bug testsuite/34183] FAIL: g++.dg/other/first-global.C scan-assembler _GLOBAL__I_foobar

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-01-05 23:08 ---
Fixed by .


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34183

[Bug c++/34551] FAIL: g++.dg/overload/arg[14].C (test for errors ...)

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2008-01-05 23:06 ---
Fixed.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34551

[Bug testsuite/34182] FAIL: g++.dg/other/datasec1.C (test for excess errors)

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-01-05 23:10 ---
Fixed by .


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34182

[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing

[jaydub66 at gmail dot com]

--- Comment #4 from jaydub66 at gmail dot com  2008-01-05 23:51 ---
But 800MB of memory is definitely *a lot* for such a small file!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683

[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing

[jaydub66 at gmail dot com]

--- Comment #3 from jaydub66 at gmail dot com  2008-01-05 23:46 ---
(In reply to comment #2)
> Can you give the output of the compiler when -ftime-report is added?

Sure thing, thanks for the remark. Here it goes:

gfortran-4.3 -c -ftime-report -O1 -fstrict-aliasing Amplitudes.f90

Execution times (seconds)
 garbage collection:   0.21 ( 0%) usr   0.02 ( 2%) sys   0.24 ( 0%) wall   
   0 kB ( 0%) ggc
 callgraph construction:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
 299 kB ( 0%) ggc
 callgraph optimization:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
  62 kB ( 0%) ggc
 trivially dead code   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 df reaching defs  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 df live regs  :   0.10 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall   
   0 kB ( 0%) ggc
 df live&initialized regs:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
 0 kB ( 0%) ggc
 df reg dead/unused notes:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
   127 kB ( 0%) ggc
 register information  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 alias analysis:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 196 kB ( 0%) ggc
 rebuild jump labels   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 parser:   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall   
1848 kB ( 0%) ggc
 inline heuristics :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   1 kB ( 0%) ggc
 tree gimplify :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
 847 kB ( 0%) ggc
 tree CFG construction :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 769 kB ( 0%) ggc
 tree CFG cleanup  :   4.20 ( 5%) usr   0.06 ( 7%) sys   4.60 ( 5%) wall   
2550 kB ( 0%) ggc
 tree copy propagation :   0.25 ( 0%) usr   0.01 ( 1%) sys   0.31 ( 0%) wall   
  24 kB ( 0%) ggc
 tree PTA  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
  67 kB ( 0%) ggc
 tree alias analysis   :   0.01 ( 0%) usr   0.01 ( 1%) sys   0.01 ( 0%) wall   
   2 kB ( 0%) ggc
 tree call clobbering  :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 tree flow sensitive alias:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 16 kB ( 0%) ggc
 tree memory partitioning:   0.07 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall 
 0 kB ( 0%) ggc
 tree SSA rewrite  :   0.48 ( 1%) usr   0.01 ( 1%) sys   0.53 ( 1%) wall   
8455 kB ( 1%) ggc
 tree SSA other:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA incremental  :   3.26 ( 4%) usr   0.08 ( 9%) sys   3.62 ( 4%) wall  
19615 kB ( 2%) ggc
 tree operand scan :  49.67 (63%) usr   0.48 (52%) sys  57.11 (64%) wall 
247409 kB (30%) ggc
 dominator optimization:   0.85 ( 1%) usr   0.02 ( 2%) sys   1.57 ( 2%) wall  
14019 kB ( 2%) ggc
 tree SRA  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
  27 kB ( 0%) ggc
 tree STORE-CCP:   0.09 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall   
   1 kB ( 0%) ggc
 tree CCP  :   0.07 ( 0%) usr   0.01 ( 1%) sys   0.08 ( 0%) wall   
  15 kB ( 0%) ggc
 tree PHI const/copy prop:   0.35 ( 0%) usr   0.00 ( 0%) sys   0.37 ( 0%) wall 
 0 kB ( 0%) ggc
 tree split crit edges :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
2489 kB ( 0%) ggc
 tree reassociation:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
  72 kB ( 0%) ggc
 tree FRE  :  16.12 (20%) usr   0.17 (18%) sys  16.75 (19%) wall 
505793 kB (62%) ggc
 tree code sinking :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
  41 kB ( 0%) ggc
 tree forward propagate:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   7 kB ( 0%) ggc
 tree conservative DCE :   0.18 ( 0%) usr   0.00 ( 0%) sys   0.19 ( 0%) wall   
   0 kB ( 0%) ggc
 tree aggressive DCE   :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 tree DSE  :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
1879 kB ( 0%) ggc
 tree loop bounds  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
 160 kB ( 0%) ggc
 loop invariant motion :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   1 kB ( 0%) ggc
 tree canonical iv :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
 138 kB ( 0%) ggc
 scev constant prop:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
  68 kB ( 0%) ggc
 complete unrolling:   0.30 ( 0%) usr   0.01 ( 1%) sys   0.36 ( 0%) wall   
2694 kB ( 0%) ggc
 tree iv optimization  :   0.17 ( 0%) usr   0.00 ( 0%) sys   0.20 ( 0%) wall   
3958 kB ( 0%) ggc
 tree loop init:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
  52 kB ( 0%) ggc
 tree copy headers :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
1280 kB ( 0%) ggc
 tree SSA uncprop  :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.

[Bug tree-optimization/34683] New: compile-time problem with -fstrict-aliasing

[jaydub66 at gmail dot com]

The attached Fortran file takes unusually long to compile with full
optimization on the latest GCC trunk builds. I tried a lot of the optimization
flags, and found that -fstrict-aliasing seems to trigger the long compile-time.

Without this flag the compile-time is perfectly reasonable, as you can see from
the following numbers (using trunk revision 131325 on i686-pc-linux-gnu,
Pentium M 1,7Ghz and 1GB memory):

-O0: 0.9s
-O1: 4.5s
-O2 -fno-strict-aliasing:  8.0s
-O3 -fno-strict-aliasing: 10.4s

But once I use -fstrict-aliasing, compile-time explodes:

-O1 -fstrict-aliasing: 1m10s
-O2: 2m16s
-O3: 1m43s

(-fstrict-aliasing is included in -O2 and -O3, but not in -O1)
I don't know why -O3 is faster than -O2 here (which seems funny), but anyway
all three numbers are way too large in my opinion. I mean: compile-time rises
by a factor of roughly 15, just due to this one flag! I don't even know what
the flag is supposed to do for this code. Maybe someone can explain this to me?

I didn't examine memory consumption very carefully, but this also seems
unusually high, as a similar file failed to compile on an old machine (with
only 256MB) due to lack of memory(!).

Am I right to assume that something goes wrong here somehow, or can someone
tell me why I should expect this kind of behaviour for this code?


-- 
   Summary: compile-time problem with -fstrict-aliasing
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaydub66 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683

[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing

[jaydub66 at gmail dot com]

--- Comment #1 from jaydub66 at gmail dot com  2008-01-05 23:36 ---
Created an attachment (id=14885)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14885&action=view)
test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683

[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-01-05 23:37 ---
Can you give the output of the compiler when -ftime-report is added?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683

[Bug fortran/34410] gamma_5.f90 segfault on Cygwin

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-01-06 00:54 
---
This bug has gone away. gamma_5.f90 passes 


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34410

[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-01-06 00:36 
---
Confirmed: Some comparative timings with Intel and Sun compilers which also use
very little memory.

$ time gfc -c -O2 janus_slow.f90 

real2m53.448s
user2m51.425s
sys 0m1.878s
$ time ifort -c -O2 janus_slow.f90 

real0m10.489s
user0m10.264s
sys 0m0.185s
$ time sunf95 -c -O2 janus_slow.f90 

real0m24.029s
user0m23.339s
sys 0m0.685s


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-06 00:36:29
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683

[Bug c++/34684] New: Cross DLL Exceptions

[XuHotdogs at gmail dot com]

Exceptions cannot escape DLL boundaries, that is, when I throw an exception in
one DLL and place a try/catch block in another EXE executable that dynamically
loads the DLL, the exception cannot be catched! Instead, the system issues an
error message and abort.
I noticed that this problem was once fixed in one of the MinGW Project's
releases, but the patch was not merged into GCC's main development sources.
Can anyone tell me what I can do or just fix the problem?
Thanks a lot!


-- 
   Summary: Cross DLL Exceptions
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: XuHotdogs at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34684