[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #32 from jpr at csc dot fi  2008-02-09 06:46 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP


hi,

the patch looks good to me, although from the clarity point of view and 
to avoid potential problem with other thread models, i'd go all the way 
and introduce the __gthread_mutex_destroy() function in the  gcc/gthr*.h 
files.

juha

>
>
> --- Comment #29 from jvdelisle at gcc dot gnu dot org  2008-02-08 18:10 
> ---
> Created an attachment (id=15118)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15118&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15118&action=view)
> Proposed patch, needs testing on mingw
>
> Here is the patch.  I have tested this on Cygwin, but not mingw.  It is
> regression testing on x86-64.  A previous version passed regression testing,
> but I am retesting after clean-up.
>
> I would appreciate if others would review/test this patch.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug fortran/35009] error on valid with -std=f95 (character arrays in format tags)

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2008-02-09 06:14 ---
(In reply to comment #2

FX,

I think that your logic is impeccable - I am sure that is the correct fix.

Cheers

Paul


-- 


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

[Bug c++/35145] Mozilla stable branch (1.8) fails to build with gcc 4.3.0

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-09 05:44 ---
Is nsDirectoryIteratorImpl::Create defined anywhere in the sources of the
shared library?  How is nsDirectoryIteratorImpl declared, does it have a
visibility hidden on it?  If the first one is false and the second one is true,
then this is not a bug in GCC but in Mozilla's sources.  


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/35145] Mozilla stable branch (1.8) fails to build with gcc 4.3.0

[kengert at redhat dot com]

--- Comment #2 from kengert at redhat dot com  2008-02-09 05:32 ---
It appears there is some sort of visibility issue, I should have had this idea
earlier because of the "hidden symbol" message shown in the build output.

The mozilla build system has a configuration option to disable the visibility
feature, as I understand it.

Once I pass 
  ac_cv_visibility_pragma=no
to the mozilla configure scripts, it works.

(FYI the comments for that mozilla build option point to gcc bug 26905 and gcc
bug 20297.)


-- 


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

[Bug c++/13903] using namespace X does not work for operator new

[gilad at odinak dot com]

--- Comment #7 from gilad at odinak dot com  2008-02-09 04:18 ---
Thanks by the way there's a typo in the spec locator it is not static but
sometimes std and sometimes stc see here for the original suggestion to change
the behavior
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0727.htm
no rationale of course


-- 


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

[Bug c++/35144] [4.3 regression] ICE in generate_element_copy

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-09 03:55 ---
  x ={v} x.2;

  struct
  {
B:: * __pfn;
int __delta;
  } x;
  struct
  {
B:: * __pfn;
int __delta;
  } x.2;

I think this is either an inlining issue or a C++ front-end issue (well I
thinking it is more of a C++ issue as the structs should be the same anyways).

(gdb) p src.element.common.type
$3 = (tree) 0x43cdd930
(gdb) p dst.element.common.type
$4 = (tree) 0x43cdd1c0

-- Pinski


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |c++
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-02-09 03:55:16
   date||


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

[Bug c++/35116] [4.3 Regression]: Fail to compile valid code

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-02-09 03:40 ---
Subject: Bug 35116

Author: jason
Date: Sat Feb  9 03:40:14 2008
New Revision: 132197

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132197
Log:
PR c++/35116
* tree.c (build_target_expr_with_type): Handle void initializer.
(bot_manip): Remap slot before recursing.

Added:
trunk/gcc/testsuite/g++.dg/init/value2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c


-- 


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

[Bug c++/35146] weird error in template function specialization

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-09 01:45 ---
This works fine on the trunk.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.0


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

[Bug c/34710] FORTIFY_SOURCE matches to many patterns

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2008-02-09 01:41 ---
(In reply to comment #8)
> I've read this section of the standard, and don't see that
> it is applicable. "Any function declared in a header may be additionally
> implemented as a function-like macro defined in the header, so if a
> library function is declared explicitly when its header is included, one
> of the techniques shown below can be used to ensure the declaration is
> not affected by such a macro."

Huh???  Look, fprintf becomes a function like macro, you use it was a function
like macro when you do:
p.fprintf(&p, "%i", 123);


So Guess what the preprocessor happens before the rest of the processing so you
end up with the macro function substation and you get the incorrect result you
wantted.  so again there is no issue inside GCC.


-- 


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

[Bug c++/35146] New: weird error in template function specialization

[grey_earl at web dot de]

gcc -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--disable-libmudflap --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 20080114 (prerelease) (Debian 4.2.2-7)


The error:
schroed2.cpp: In function ‘void blas_scal(typename ref::result,
complex*) [with T = double]’:
schroed2.cpp:16: error: cannot convert ‘complex’ to ‘double’
for argument ‘1’ to ‘void cblas_zdscal(double, void*)’


The code:
template  struct complex { T re; T im; };

template  struct ref { typedef const R& result; };
template <> struct ref { typedef double result; };
template <> struct ref > { typedef complex result; };

void cblas_dscal(double alpha, double *x) { }
void cblas_zscal(void *alpha, void *x) { }
void cblas_zdscal(double alpha, void *x) { }

template  void blas_scal(typename ref::result alpha, T* x);
template  void blas_scal(typename ref::result alpha, complex*
x);

template <> void blas_scal(double alpha, double* x) { cblas_dscal(alpha, x); }
template <> void blas_scal(complex alpha, complex* x) {
complex cblas_alpha = alpha; cblas_zscal(&cblas_alpha, x); }
template <> void blas_scal(double alpha, complex* x) {
cblas_zdscal(alpha, x); } // line 16 is here

int main() {
  return 0;
}


The ref-struct allows to use pass-by-reference for big datatypes, pass-by-value
for small ones. If I replace this struct in the template declaration for
blas_scal by T, everything works as expected. For T = double, the last
specialization is imho valid for the second template declaration - I don't even
know what gcc wants from me, since the parameters are exactly what is needed.


-- 
   Summary: weird error in template function specialization
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grey_earl at web dot de


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

[Bug c/34710] FORTIFY_SOURCE matches to many patterns

[graeme at argyllcms dot com]

--- Comment #8 from graeme at argyllcms dot com  2008-02-09 01:37 ---
I've read this section of the standard, and don't see that
it is applicable. "Any function declared in a header may be additionally
implemented as a function-like macro defined in the header, so if a
library function is declared explicitly when its header is included, one
of the techniques shown below can be used to ensure the declaration is
not affected by such a macro."

This isn't applicable, since I'm not explicitly declaring the library
function fprintf. What I'm declaring is my function (that happens to
be called fprintf) as a member of a structure. They are two distinct
names and functions in different scopes.

The problem is that the function-like macro is being (wrongly) substituted
for something that isn't the library function declared in the header.

To claim that including a header makes all the identifiers in that
header reserved words for everything is simply unworkable I think.
Why is a #include file special code that doesn't obey the language scoping
rules ? Modern systems may have countless thousands of identifiers in their
headers, so how can anyone sitting down to do some programming avoid
using any of them for anything, including what are normally
private scope identifiers such as structure member names ?
This is exactly the opposite of modularization and information hiding!


-- 


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

[Bug c++/35145] Mozilla stable branch (1.8) fails to build with gcc 4.3.0

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-09 01:09 ---
This seriously does not sounds like a GCC bug.  Note for other people who are
playing at home:

nsXPCOMObsolete.o:(.data.rel.ro+0x18): undefined reference to
`nsFileSpecImpl::Create(nsISupports*, nsID const&, void**)'
nsXPCOMObsolete.o:(.data.rel.ro+0x50): undefined reference to
`nsDirectoryIteratorImpl::Create(nsISupports*, nsID const&, void**)'
/usr/bin/ld: libxpcom_compat_c.so: hidden symbol
`nsFileSpecImpl::Create(nsISupports*, nsID const&, void**)' isn't defined

-- Pinski


-- 


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

[Bug c++/35145] New: Mozilla stable branch (1.8) fails to build with gcc 4.3.0

[kengert at redhat dot com]

OS environment: Latest Fedora Rawhide nightly tree.
cpp-4.3.0-0.7.i386
libgcc-4.3.0-0.7.i386
libstdc++-4.3.0-0.7.i386
gcc-4.3.0-0.7.i386
gcc-c++-4.3.0-0.7.i386

Attempting to build SeaMonkey 1.1.8, which uses the same tree as stable Firefox
2.0.0.x. (The failure is in the early core components of Mozilla, so the actual
Mozilla variation should be irrelevant)

I don't know yet where the cause of the problem is, it might be in gcc, or it
might be bad Mozilla code.

To make people aware, I have filed additional bugs here:
  https://bugzilla.redhat.com/show_bug.cgi?id=432138
  https://bugzilla.mozilla.org/show_bug.cgi?id=416463


-- 
   Summary: Mozilla stable branch (1.8) fails to build with gcc
4.3.0
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kengert at redhat dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug middle-end/34627] Incorrect branching with -Ox on hppa

[danglin at gcc dot gnu dot org]

--- Comment #22 from danglin at gcc dot gnu dot org  2008-02-09 00:39 
---
Fixed.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/34627] Incorrect branching with -Ox on hppa

[danglin at gcc dot gnu dot org]

--- Comment #21 from danglin at gcc dot gnu dot org  2008-02-09 00:37 
---
Subject: Bug 34627

Author: danglin
Date: Sat Feb  9 00:37:00 2008
New Revision: 132195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132195
Log:
PR middle-end/34627
combine.c (simplify_if_then_else): Make sure the comparison is
against const0_rtx when simplifying to (abs x) or (neg (abs X)).


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/combine.c


-- 


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

[Bug middle-end/34627] Incorrect branching with -Ox on hppa

[danglin at gcc dot gnu dot org]

--- Comment #20 from danglin at gcc dot gnu dot org  2008-02-09 00:35 
---
Subject: Bug 34627

Author: danglin
Date: Sat Feb  9 00:34:19 2008
New Revision: 132194

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132194
Log:
PR middle-end/34627
combine.c (simplify_if_then_else): Make sure the comparison is
against const0_rtx when simplifying to (abs x) or (neg (abs X)).


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/combine.c


-- 


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

[Bug middle-end/34627] Incorrect branching with -Ox on hppa

[danglin at gcc dot gnu dot org]

--- Comment #19 from danglin at gcc dot gnu dot org  2008-02-09 00:31 
---
Subject: Bug 34627

Author: danglin
Date: Sat Feb  9 00:30:13 2008
New Revision: 132193

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132193
Log:
PR middle-end/34627
combine.c (simplify_if_then_else): Make sure the comparison is
against const0_rtx when simplifying to (abs x) or (neg (abs X)).


Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c


-- 


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

[Bug c++/13903] using namespace X does not work for operator new

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2008-02-09 00:23 ---
(In reply to comment #5)
> Could you please tell me which standard does not allow it, and if a previous
> standard does allow it.

The only thing I can tell you is that in our codebase the code is commented as:

   /* [basic.std.dynamic.allocation]/1:

   A program is ill-formed if an allocation function is declared
   in a namespace scope other than global scope or declared static
   in global scope.

   The same also holds true for deallocation functions.  */

where the first line is a reference to the ISO C++ standard.

Anyway, this is not the appropriate place to get help with C++.


-- 


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

[Bug c/34710] FORTIFY_SOURCE matches to many patterns

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-02-09 00:21 ---
(In reply to comment #5)
> The code is not "buggy". printf and fprintf are not reserved words, and
> occupy a separate namespace with regard to the structure name and any
> global function names. 

No they can be function macros if you include stdio.h, please read the
standard.

>From C99 (7.1.4/1):
Any function declared in a header may be additionally implemented as a
function-likemacro defined in the header, so if a library function is declared
explicitly when its header is included, one 
of the techniques shown belowcan be used to ensure the declaration is not
affected by 
such a macro.


So you can do:

p.(fprintf)(&p, "%i", 123);

or
#undef fprintf after including stdio.h.


-- 


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

[Bug c/34710] FORTIFY_SOURCE matches to many patterns

[schwab at suse dot de]

--- Comment #6 from schwab at suse dot de  2008-02-09 00:20 ---
As soon as  is included fprintf becomes reserved as a function like
macro.  That is independent of _FORTIFY_SOURCE, and is true for every function
defined in the standard C libaray.


-- 


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

[Bug c/34710] FORTIFY_SOURCE matches to many patterns

[graeme at argyllcms dot com]

--- Comment #5 from graeme at argyllcms dot com  2008-02-09 00:04 ---
The code is not "buggy". printf and fprintf are not reserved words, and
occupy a separate namespace with regard to the structure name and any
global function names. Because macros are a pre-process and don't understand
the language syntax, they don't respect the difference in namespace
and are therefore inherently dangerous and not guaranteed to work as
a mechanism to change the number of arguments to a function.

Ideally FORTIFY_SOURCE should use some other mechanism
that does respect the name spaces.


-- 


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

[Bug ada/35143] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #5 from joel at gcc dot gnu dot org  2008-02-08 23:19 ---
Created an attachment (id=15123)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15123&action=view)
Laurent Guerby's exception test


With SVN, the output is

Raising Constraint_Error

raised CONSTRAINT_ERROR : exception_test.adb:11 explicit raise

With 4.2.3, the output is:

Raising Constraint_Error
Caught Constraint_Error -- inner

Same RTEMS library binary in both cases.  So any tool version issues with that
code is NOT a factor.


-- 


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

[Bug ada/35143] Serious regression on ACATS results since 4.2.3

[laurent at guerby dot net]

--- Comment #4 from laurent at guerby dot net  2008-02-08 23:15 ---
I looked at several FAIL and it looks like exception are raised as expected by
the tests but they are not catched.

What doesn't work seem to be exception propagation.

I think I gave you a little Ada exception test a while ago, did you run it on
this target?


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug tree-optimization/35144] New: [4.3 regression] ICE in generate_element_copy

[jakub at gcc dot gnu dot org]

struct A
{
  int baz ();
};

typedef int (A::*P) ();

struct B
{
  B ();
  int foo (P x, int y = 0);
};

struct C
{
  typedef int (B::*Q) (P, int);
  void bar (Q x) { c = x; }
  Q c;
};

extern C c;

B::B ()
{
 c.bar ((C::Q) &B::foo);
}

ICEs with:
internal compiler error: in generate_element_copy, at tree-sra.c:2603
at -O and above on x86_64-linux (-m64 as well as -m32).
Revision 126202 still works, 126654 already ICEs.


-- 
   Summary: [4.3 regression] ICE in generate_element_copy
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug ada/35143] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-02-08 23:06 ---
Created an attachment (id=15122)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15122&action=view)
Same patch but against 4.2.3

Just as a sanity measure.  This is the same patch but against 4.2.3.  4.2.3
works great on the ACATS.  SVN has lots of problems unrelated to RTEMS
specifically.


-- 


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

[Bug tree-optimization/35144] [4.3 regression] ICE in generate_element_copy

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2008-02-08 23:05 ---
Is it possible to create an equivalent C test case (e.g. from the initial
GIMPLE dumps before the ICE)?


-- 


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

[Bug ada/35143] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-02-08 23:04 ---
Created an attachment (id=15121)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15121&action=view)
RTEM SVN Trunk Ada Patch

Unfortunately, I have an outstanding patch that did not get reviewed in time
for inclusion in 4.3.  It has been posted in multiple forms but this is the
latest.  A similar patch is used against 4.2.3.  


-- 


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

[Bug ada/35143] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-02-08 23:01 ---
Created an attachment (id=15120)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15120&action=view)
ACATS Log for powerpc-rtems4.9 SVN trunk rev 132186


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at verizon dot net]

--- Comment #31 from jvdelisle at verizon dot net  2008-02-08 23:00 ---
Subject: Re:  [Regression wrt g77] I/O leaks
 handles/memory on Windows XP

mikko dot lyly at csc dot fi wrote:
> --- Comment #30 from mikko dot lyly at csc dot fi  2008-02-08 22:31 
> ---
>> I would appreciate if others would review/test this patch.
> 
> I have applied this patch against rev 132188 on mingw32.
> 
> The problem described in comments #1 and #7 for internal and external units,
> rspectively, seems to be resolved.
> 

Thanks for testing and the report.


-- 


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

[Bug ada/35143] New: Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

4.2.3: PASSED: 2309 FAILED3
Trunk: PASSED: 1623 FAILED  689

4.2.3 only failed c380004, c761007, and c953002.

I am posting the full log for the SVN trunk as an attachment.  Hopefully
someone can spot a pattern and we can start to file appropriate PRs.  This is a
big regression.


-- 
   Summary: Serious regression on ACATS results since 4.2.3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: powerpc-rtems4.9


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

[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-08 22:50 ---
4.2 works for me.  This is a middle-end/tree-optimization problem.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|ada |middle-end
  Known to work||4.2.3


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

[Bug ada/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-08 22:39:21
   date||


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

[Bug middle-end/35142] MMX bad optimization with intrinsics

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-08 22:38 ---
With gcc 4.3:

_Z3fooR1XRKS_:
.LFB124:
subl$20, %esp
.LCFI0:
movl24(%esp), %eax
movl28(%esp), %edx
movq(%eax), %mm0
pxor(%edx), %mm0
movq%mm0, (%eax)
movq8(%eax), %mm0
pxor8(%edx), %mm0
movq%mm0, 8(%eax)
addl$20, %esp
ret
.LFE124:


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
  Known to fail||4.2.3
  Known to work||4.3.0
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[mikko dot lyly at csc dot fi]

--- Comment #30 from mikko dot lyly at csc dot fi  2008-02-08 22:31 ---
> I would appreciate if others would review/test this patch.

I have applied this patch against rev 132188 on mingw32.

The problem described in comments #1 and #7 for internal and external units,
rspectively, seems to be resolved.

$ /c/gcc-patched/mingw/bin/gfortran-patched.exe -v   
Using built-in specs.
Target: mingw32
Configured with: ../gcc/configure --with-gcc --host=mingw32 --build=mingw32
--target=mingw32 --with-arch=i486 --with-tune=generic --program-suffix=-patched
--disable-werror --prefix=/mingw --with-local-prefix=/mingw --disable-nls
--enable-languages=c,fortran --disable-win32-registry --enable-threads
--enable-sjlj-exceptions --enable-libstdcxx-debug
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--enable-version-specific-runtime-libs --disable-bootstrap
Thread model: win32
gcc version 4.3.0 20080208 (experimental) (GCC) 


-- 


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

[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-08 22:20 ---
Not with this testcase.


-- 


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

[Bug c/35142] New: MMX bad optimization with intrinsics

[etjq78kl at free dot fr]

--- Short description

Use of xmm intrinsics generates useless code: mmx registers seem to be written
back to the stack systematicaly, even when this is not needed. Maybe it's
related to already reported bug about MMX.

--- GCC version (4.2.1, prebuild version for mingw)

Bugs was seen at least with 4.0.x and 4.1.x, under linux as well. I don't
remember exact build params, but as long as I remember this prevented me to use
mmx intrinsics.

-march=pentium4 option is irelevant (command line below). Use donly to enable
mmx/sse.

> g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure --with-gcc --enable-libgomp
--host=mingw32 --build=mingw32 --target=mingw32 --program-suffix=-dw2
--with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw
--with-local-prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry
--disable-sjlj-exceptions --enable-libstdcxx-debug
--enable-cxx-flags=-fno-function-sections -fno-data-sections
--enable-version-specific-runtime-libs --disable-bootstrap
Thread model: win32
gcc version 4.2.1-dw2 (mingw32-2)

--- Source code ---

> cat bug.cc

#if defined (SSE)
#include 
#elif defined (MMX)
#include 
#endif

struct X {
#if defined (SSE)
  __m128i data[2];
#elif defined (MMX)
  __m64   data[2];
#else
  int data[2];
#endif
};

void foo (X& a, const X& b)
{
  for (int k = 0; k < 2; ++k) {
#if defined (SSE)
a.data[k] = _mm_xor_si128 (a.data[k], b.data[k]);
#elif defined (MMX)
a.data[k] = _mm_xor_si64 (a.data[k], b.data[k]);
#else
a.data[k] ^= b.data[k];
#endif
  }
}

--- Assembly (SSE, OK)

> g++ -S -O3 bug.cc -DSSE -march=pentium4 -fomit-frame-pointer

.globl __Z3fooR1XRKS_
.def__Z3fooR1XRKS_; .scl2;  .type   32; .endef
__Z3fooR1XRKS_:
LFB472:
movl4(%esp), %eax
movl8(%esp), %edx
movdqa  (%eax), %xmm0
pxor(%edx), %xmm0
movdqa  %xmm0, (%eax)
movdqa  16(%eax), %xmm0
pxor16(%edx), %xmm0
movdqa  %xmm0, 16(%eax)
ret
LFE472:

--- Assembly (MMX, BAD)

> g++ -S -O3 bug.cc -DMMX -march=pentium4 -fomit-frame-pointer

.globl __Z3fooR1XRKS_
.def__Z3fooR1XRKS_; .scl2;  .type   32; .endef
__Z3fooR1XRKS_:
LFB124:
subl$20, %esp   <--- Useless
LCFI0:
movl24(%esp), %eax
movl28(%esp), %edx
movq(%eax), %mm0
movq%mm0, 8(%esp)   <--- Useless
pxor(%edx), %mm0
movq%mm0, (%eax)
movq8(%eax), %mm0
movq%mm0, (%esp)<--- Useless
pxor8(%edx), %mm0
movq%mm0, 8(%eax)
addl$20, %esp   <--- Useless
ret
LFE124:


-- 
   Summary: MMX bad optimization with intrinsics
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etjq78kl at free dot fr


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

[Bug c++/35138] [4.3 Regression] g++ rejects valid code

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-08 22:15 ---
This is worse than PR32384, so either we have a fix for it or we should revert
the fix for PR32384 before 4.3.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32384
  nThis||
   Priority|P3  |P1


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

[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list

[bangerth at dealii dot org]

--- Comment #4 from bangerth at dealii dot org  2008-02-08 21:59 ---
Can this be reproduced with gcc 4.2.x or current mainline?


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug c++/35138] [4.3 Regression] g++ rejects valid code

[bangerth at dealii dot org]

--- Comment #4 from bangerth at dealii dot org  2008-02-08 21:51 ---
This should get higher priority than P3...


-- 


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-02-08 21:40 
---
How does this look  :)  I have a couple of other test prints in there.

$ gfc pr35132.f90 
$ ./a.out
 1st: 123456
 2nd: abcdef
123456
ASDFef
At line 26 of file pr35132.f90 (unit = 20, file = 'foo.txt')
Fortran runtime error: End of file


-- 


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

[Bug bootstrap/33992] [4.3 Regression] profiledbootstrap is broken

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2008-02-08 21:29 
---
Now that we have a testcase.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P2  |P1


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

[Bug bootstrap/33992] [4.3 Regression] profiledbootstrap is broken

[ubizjak at gmail dot com]

--- Comment #22 from ubizjak at gmail dot com  2008-02-08 21:17 ---
Created an attachment (id=15119)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15119&action=view)
Executable test that shows the failure.

This is the test that shows the inliner failure:

[EMAIL PROTECTED] ~]$ gcc -O2 test.c
[EMAIL PROTECTED] ~]$ ./a.out
uexp=213
sig[0]=5834422113351499776
sig[1]=4377335499248575995
sig[2]=14012984643248170709

[EMAIL PROTECTED] ~]$ gcc -O2 -DINLINE test.c
[EMAIL PROTECTED] ~]$ ./a.out
uexp=212
sig[0]=11668844226702999552
sig[1]=1837141970856070134
sig[2]=9579225209565564328

The first result is correct, the second is not.


-- 


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-02-08 20:47 
---
I will take this one.


-- 

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|2008-02-07 22:52:03 |2008-02-08 20:47:47
   date||


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

[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity

[alexandre dot nunes at gmail dot com]

--- Comment #3 from alexandre dot nunes at gmail dot com  2008-02-08 20:48 
---
(In reply to comment #2)
> Also using a volatile pointer may prevent optimization, so don't use it if
> not strictly needed (or at least don't expect optimized code).
> 

Sorry for lefting it in there: Tought the above code snippet was from real code
that writes to a hardware register, the compiler generates exactly the same
output with or without the volatile, thus that's irrelevant for this bug
report. 

I hope I don't confuse testing on future compiler versions, where it may end up
 making any difference. 

> Can you try 4.3 as suggested?
> 

Yes, if/when I can get it to compile. I'll post back in a few days.


-- 


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

[Bug bootstrap/33992] [4.3 Regression] profiledbootstrap is broken

[ubizjak at gmail dot com]

--- Comment #21 from ubizjak at gmail dot com  2008-02-08 20:25 ---
Following patch that forces inlining of normalize breaks normal bootstrap in
exactly the same way, so it looks that there is something wrong with inliner.

Index: real.c
===
--- real.c  (revision 132182)
+++ real.c  (working copy)
@@ -98,7 +98,7 @@
 static void clear_significand_below (REAL_VALUE_TYPE *, unsigned int);
 static bool div_significands (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *,
  const REAL_VALUE_TYPE *);
-static void normalize (REAL_VALUE_TYPE *);
+static inline void normalize (REAL_VALUE_TYPE *)
__attribute__((always_inline));

 static bool do_add (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *,
const REAL_VALUE_TYPE *, int);


:0: internal compiler error: in real_to_decimal, at
real.c:1656:0: internal compiler error: in real_to_decimal, at
real.c:1656
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug bootstrap/33992] [4.3 Regression] profiledbootstrap is broken

[ubizjak at gmail dot com]

--- Comment #20 from ubizjak at gmail dot com  2008-02-08 20:15 ---
(In reply to comment #19)

> So, what upsets gcc's inliner/profiler/whatever to drop the call?

Correction, normalize() gets inlined together with lshift_significand(), but
there is something wrong with inlined version. Adding attribute ((noinline))
only to lshift_significand() doesn't fix the failure.


-- 


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

[Bug libobjc/23681] CLS_HAS_CXX_STRUCTORS is not supported with the GNU runtime

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-08 20:14 ---
*** Bug 27247 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug objc++/27247] FAIL: obj-c++.dg/cxx-ivars-2.mm execution test

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-02-08 20:14 ---
This is a dup of bug 23681.  I Need to add support to libobjc for this but I
have not yet.

*** This bug has been marked as a duplicate of 23681 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/35051] [4.3 Regression] Build machine requires GMP and MPFR for building cross-host gccs

[rsandifo at gcc dot gnu dot org]

--- Comment #5 from rsandifo at gcc dot gnu dot org  2008-02-08 19:11 
---
Patch applied.  Thanks to Richard G. for the review.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/35051] [4.3 Regression] Build machine requires GMP and MPFR for building cross-host gccs

[rsandifo at gcc dot gnu dot org]

--- Comment #4 from rsandifo at gcc dot gnu dot org  2008-02-08 19:11 
---
Subject: Bug 35051

Author: rsandifo
Date: Fri Feb  8 19:10:25 2008
New Revision: 132188

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132188
Log:
gcc/
PR bootstrap/35051
* double-int.h: Don't include gmp.h for GENERATOR_FILEs.
(mpz_set_double_int, mpz_get_double_int): Hide from GENERATOR_FILEs.
* real.h: Don't include gmp.h or mpfr.h for GENERATOR_FILEs.
(real_from_mpfr, mpfr_from_real): Hide from GENERATOR_FILEs.
* tree.h (get_type_static_bounds): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/double-int.h
trunk/gcc/real.h
trunk/gcc/tree.h


-- 


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

[Bug c/35141] ARM: Constant generation inside a loop: Missed optimization opportunity

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-08 18:37 ---
Also using a volatile pointer may prevent optimization, so don't use it if
not strictly needed (or at least don't expect optimized code).

Can you try 4.3 as suggested?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/13903] using namespace X does not work for operator new

[gilad at odinak dot com]

--- Comment #5 from gilad at odinak dot com  2008-02-08 18:30 ---
Could you please tell me which standard does not allow it, and if a previous
standard does allow it.
It is the only way I found to avoid the memory allocator in my code from
colliding with the memory allocator of a library (that is the functionality did
work)


-- 


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

[Bug objc++/27247] FAIL: obj-c++.dg/cxx-ivars-2.mm execution test

[ghazi at gcc dot gnu dot org]

--- Comment #3 from ghazi at gcc dot gnu dot org  2008-02-08 18:21 ---
Below is what I get from gdb with mainline on x86_64-unknown-linux-gnu.  We're
aborting because the constructor for Baz's "struct bar" member isn't called.

(gdb) run
Starting program:
/home/ghazi/gcc-testing/43/build/gcc/testsuite/obj-c++/cxx-ivars-2.exe

Program received signal SIGABRT, Aborted.
0x2af76a25407b in raise () from /lib/libc.so.6
(gdb) bt full
#0  0x2af76a25407b in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x2af76a25584e in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x004008fb in main () at
/home/ghazi/gcc-testing/43/egcc-SVN20080208/gcc/testsuite/obj-c++.dg/cxx-ivars-2.mm:59
baz = (class Baz *) 0x504f50
foo = (class Foo *) 0x0
(gdb) up
#1  0x2af76a25584e in abort () from /lib/libc.so.6
(gdb) up
#2  0x004008fb in main () at testsuite/obj-c++.dg/cxx-ivars-2.mm:59
59CHECK_IF(ctor1_called && !ctor2_called && !dtor1_called);
Current language:  auto; currently minimal
(gdb) p ctor1_called
$1 = 0
(gdb) p ctor2_called
$2 = 0
(gdb) p dtor1_called
$3 = 0
(gdb) p baz.aa.a
$4 = 0
(gdb) p baz.aa.b
$5 = 0


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at gcc dot gnu dot org]

--- Comment #29 from jvdelisle at gcc dot gnu dot org  2008-02-08 18:10 
---
Created an attachment (id=15118)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15118&action=view)
Proposed patch, needs testing on mingw

Here is the patch.  I have tested this on Cygwin, but not mingw.  It is
regression testing on x86-64.  A previous version passed regression testing,
but I am retesting after clean-up.

I would appreciate if others would review/test this patch.


-- 


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

[Bug testsuite/23610] obj-c++.dg/bitfield-[14].mm, obj-c++.dg/layout-1.mm fails with the GNU runtime

[ghazi at gcc dot gnu dot org]

--- Comment #9 from ghazi at gcc dot gnu dot org  2008-02-08 18:05 ---
I get the "padding struct" error on all three active branches (4.1, 4.2,
trunk):

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00539.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00540.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00541.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.0   |4.1.3 4.2.4 4.3.0


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

[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test

[ghazi at gcc dot gnu dot org]

--- Comment #3 from ghazi at gcc dot gnu dot org  2008-02-08 17:58 ---
Below is the info from gdb with mainline on x86_64-linux-gnu.  We're aborting
because the encoding for BOOL* doesn't match the expected value.

(gdb) run
Starting program:
/home/ghazi/gcc-testing/43/build/gcc/testsuite/obj-c++/encode-8.exe

Program received signal SIGABRT, Aborted.
0x2ad8f2f4107b in raise () from /lib/libc.so.6
(gdb) bt full
#0  0x2ad8f2f4107b in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x2ad8f2f4284e in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x004006db in main () at testsuite/obj-c++.dg/encode-8.mm:17
BOOL_ptr = 0x4007cc "*"
char_ptr = 0x4007cc "*"
(gdb) list 17
12  int main(void) {
13const char *BOOL_ptr = @encode(BOOL *);
14const char *char_ptr = @encode(char *);
15
16if(strcmp(BOOL_ptr, "^c"))
17  abort();
18
19if(strcmp(char_ptr, "*"))
20  abort();
21


-- 


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

[Bug c++/35138] [4.3 Regression] g++ rejects valid code

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-02-08 17:58 ---
Caused by my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129836
This is during tentative parse, so I guess the errors should be suppressed.


-- 


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

[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-02-08 17:54 ---
One big problem which prevents omitting the -traditional-cpp is that comments
are not ignored. Another example of this is

   !  /*

which is regarded as the beginning of a C/C++ comment. Thus we should add two
modes to CPP, one for fixed-form and one for free-form Fortran code.


-- 


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

[Bug c/35141] ARM: Constant generation inside a loop: Missed optimization opportunity

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2008-02-08 17:27 ---
See PR31360.  May be fixed for GCC 4.3.


-- 


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

[Bug c/35141] New: ARM: Constant generation inside a loop: Missed optimization opportunity

[alexandre dot nunes at gmail dot com]

On ARM, the following C code:

void whatever(const char *pqp)
{
  volatile unsigned int *uart_thr = (typeof(uart_thr))0xE000C000;
  unsigned int ch;
  while((ch = *pqp++))
*uart_thr = ch;
}

Generates this assembler output (by means of -mcpu=arm7tdmi -O2):

whatever:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr2, [r0, #0]@ zero_extendqisi2
cmp r2, #0
@ lr needed for prologue
bxeqlr
.L4:
mov r3, #-536870912
add r3, r3, #49152
str r2, [r3, #0]
ldrbr2, [r0, #1]!   @ zero_extendqisi2
cmp r2, #0
bne .L4
bx  lr

The relevant part is the bne .L4 ; since r3 is preserved across the loop, it
could optimize for speed without space penality by generating this instead:

.L4:
mov r3, #-536870912
add r3, r3, #49152
.L5:
str r2, [r3, #0]
ldrbr2, [r0, #1]!   @ zero_extendqisi2
cmp r2, #0
bne .L5
bx  lr

... or, in other words, generating the constant only once, which saves at least
two cycles per iteration.


-- 
   Summary: ARM: Constant generation inside a loop: Missed
optimization opportunity
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
  GCC host triplet: i686-unknow-linux
GCC target triplet: arm-*-elf


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

[Bug rtl-optimization/11826] [ARM] Minor register allocation problem before function return

[alexandre dot nunes at gmail dot com]

--- Comment #4 from alexandre dot nunes at gmail dot com  2008-02-08 16:51 
---
I suggest closing this unless reproductible on gcc 4.3.x, since at least
vanilla arm-elf-gcc 4.2.2 is correct:

foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmn r1, r0
rsbeq   r0, r1, r0
rsbne   r0, r0, r1
@ lr needed for prologue
bx  lr
.size   foo, .-foo
.ident  "GCC: (GNU) 4.2.2"


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at gcc dot gnu dot org]

--- Comment #28 from jvdelisle at gcc dot gnu dot org  2008-02-08 16:33 
---
pthread_mutex_destroy() fixes the problem on Cygwin including the case in
Comment #26.  It regression tests OK on Linux-x86-64.  I am now just reviewing
to make sure we don't try to lock after a destroy, which can lead to undefined
behavior.

I will submit the patch here first since it will need to be tested on mingw.


-- 


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

[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list

[basti at fkp dot tu-darmstadt dot de]

--- Comment #3 from basti at fkp dot tu-darmstadt dot de  2008-02-08 16:32 
---
One can even omit the helper class sample and directly use a list,
bug is still there!!! 

the above mentioned work-around with -fno-strict-aliasing works, 
but still...

makes my kinda nervous about all my codes...


-- 


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

[Bug c++/35137] Linker error for static in-class members

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-08 16:12 ---
You need to provide a definition for the static data members outside of the
class body.  Like

const int T::STATIC_MEMBER_A;


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35138] [4.3 Regression] g++ rejects valid code

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-08 16:11 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
  Known to fail||4.3.0
  Known to work||4.1.2 4.2.2
   Last reconfirmed|-00-00 00:00:00 |2008-02-08 16:11:14
   date||
Summary|g++ rejects valid code  |[4.3 Regression] g++ rejects
   ||valid code
   Target Milestone|--- |4.3.0


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

[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-08 16:07 ---
This is possibly a dup of one of the various alias problems of gcc 4.1.
-fno-strict-aliasing is a workaround.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Keywords||alias, wrong-code
  Known to work|3.4.6 4.2.1 |3.4.6 4.2.1 4.3.0


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

[Bug tree-optimization/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3

[hubicka at gcc dot gnu dot org]

--- Comment #25 from hubicka at gcc dot gnu dot org  2008-02-08 15:39 
---
-fno-tree-dominator-opts -fno-tree-copyrename solves the coalescing problem
(name is introduced by second, the actual problematic pattern by first pass),
saving roughly 1s at both -O2 and 2s at -O3, -O3 is still worse however
Internal loop no longer spills, just reads val of scan_end stored in memory.

I will play with it more later and make simple testcase for this.
Honza


-- 


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

[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list

[basti at fkp dot tu-darmstadt dot de]

--- Comment #1 from basti at fkp dot tu-darmstadt dot de  2008-02-08 15:28 
---
replacing all doubles types with size_t or int does change nothing.
the bug still exists.


-- 

basti at fkp dot tu-darmstadt dot de changed:

   What|Removed |Added

 CC||basti at fkp dot tu-
   ||darmstadt dot de
  Known to fail||4.1.2 4.1.3
  Known to work||3.4.6 4.2.1
Summary|floating point error in |wrong result due to -O2
   |combination with std::list  |optimization in combination
   |with -O2 optimization turned|with std::list
   |on  |


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

[Bug tree-optimization/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3

[hubicka at gcc dot gnu dot org]

--- Comment #24 from hubicka at gcc dot gnu dot org  2008-02-08 15:11 
---
Hi,
the tonight runs with continue heuristics shows again improvements on 64bit
scores , but degradation on 32bit scores.  Looking into the loop, the real
trouble seems to be that the main loop has 6 loop carried variables:

scan_end, scan_end1, best_len, scan, chain_length, cur_match

plus few temporaries are needed too. Obviously we can't fit in registers on
i386. Making profile more realistic sometime helps sometimes hurts pretty much
at random basis.

One case where I think register presure is increased is the fact that different
SSA names of both scan_end and scan_end1 variables are actually not fully
coalesced in out-of-SSA.  This is result of optimizing:

if (match[best_len] != scan_end ||
match[best_len-1] != scan_end1 ||
*match != *scan ||
*++match != scan[1]) continue;
   ...later code sometimes modifying scan_end

into computing match[best_len] into name of scan_end that is sometimes assigned
int the later code on the path not modifying scan_end.  As a result we do have
two scan_ends live at once.  I wonder if we can avoid this behaviour, though it
looks all right on SSA form, it would save 2 "global" registers: there is no
need at all to cache match[best_len]/match[best_len1] in register unless I
missed something. Those two vars are manipulated on the hot paths through the
loop.

Now the RA is driven by frequencies (bit confused by fact that two of loop
carried vars are split) and by their "liveranges" that is actually number of
instructions in bettween first and last occurence.  Since we are bit carelless
on BB ordering moving some code to the very end of function, this heuristics is
not realistic at all.  It would probably make more sense to replace it by
number of inssn it is live across, but this is probably ninsn*npseudos to
compute. Other idea would be degree in conflict graph, but I am not sure we
want to start such experiemtns in parallel with YARA.

I tested YARA and it does not handle this situation much better. Perhaps
Vladimir can help?

Honza


-- 


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

[Bug c++/35140] New: floating point error in combination with std::list with -O2 optimization turned on

[basti at fkp dot tu-darmstadt dot de]

The following program:
//

#include
#include

class sample
{
public:
double criterium;
sample(double _criterium):criterium(_criterium) {};
}; 


int main(){

  std::list samples;
  samples.push_back(sample(1.));

  double tmp=0.;

  std::list::iterator i1;
  i1=samples.begin();   
  tmp=(*i1).criterium; 
  // !
  // THIS += operation fails
  (*i1).criterium+=2.; 
  //

  std::cout<<"tmp "< search starts here:
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i486-linux-gnu
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.2/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed tst_short.ii -quiet
-dumpbase tst_short.cpp -mtune=i686 -auxbase tst_short -g -O2 -version -o
tst_short.s
GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129483
Compiler executable checksum: 183d42a838ed2b7313bffcb8f2f2fda7
 as -V -Qy -o tst_short.o tst_short.s
GNU assembler version 2.17 (i486-linux-gnu) using BFD version 2.17 Debian
GNU/Linux
 /usr/lib/gcc/i486-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o tst_short_O2
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.1.2/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.1.2 -L/usr/lib/gcc/i486-linux-gnu/4.1.2
-L/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib -L/lib/../lib
-L/usr/lib/../lib tst_short.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i486-linux-gnu/4.1.2/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crtn.o




System 2:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
 /usr/lib/gcc/i486-linux-gnu/4.1.3/cc1plus -E -quiet -v -D_GNU_SOURCE
tst_short.cpp -mtune=generic -fpch-preprocess -o tst_short.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.1.3
 /usr/include/c++/4.1.3/i486-linux-gnu
 /usr/include/c++/4.1.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.3/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.3/cc1plus -fpreprocessed tst_short.ii -quiet
-dumpbase tst_short.cpp -mtune=generic -auxbase tst_short -version
-fstack-protector -fstack-protector -o tst_short.s
GNU C++ version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
(i486-linux-gnu)
compiled by GNU C version 4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64316
Compiler executable checksum: 3cc47be363985179cfafdceddd0e8f5d
 as --traditional-format -V -Qy -o tst_short.o tst_short.s
GNU assembler version 2.18 (i486-linux-gnu) using BFD version (GNU Binutils for
Ubuntu) 2.18
 /usr/lib/gcc/i486-linux-gnu/4.1.3/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o tst_short
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.1.3 -L/usr/lib/gcc/i486-linux-gnu/4.1.3
-L/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib tst_short.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i486-linux-gnu/4.1.3/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crtn.o


-- 
   Summary: floating point error in combination with std::list with
-O2 optimization turned on
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: basti at fkp dot tu-darmstadt dot de


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at gcc dot gnu dot org]

--- Comment #27 from jvdelisle at gcc dot gnu dot org  2008-02-08 14:58 
---
OK OK I believe you.  :)  What the heck was I looking at before?  :)  I am just
working up the closehandle patch now.


-- 


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

[Bug target/23322] [4.1/4.2/4.3 regression] performance regression

[hubicka at gcc dot gnu dot org]

--- Comment #29 from hubicka at gcc dot gnu dot org  2008-02-08 14:54 
---
Hi,
tonight results from Haydn shows 32bit scores with the loop-invariant hack
disabled.
http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/index.html

There are no off noise speedups though I must admit that the 32bit results from
Haydn are truly noisy. I also did runs by hand and those also don't seem much
difference, but the noise factor is always dificult to estimate in little stuff
like this.

I will give it a run on britten too to double check, it was running different
patch tonight.

However I wonder if you do have testcases where the hack helps. In general we
can

1) ignore the problem
2) disable the hack for loop-invariant only (not for GCSE). Loop-invariant is
more sure about benefits and already has some heuristics to limit the pressure.
 I do agree that in general having too many stuff in x87 registers kills the
perofmrance on very random basis.
3) come up with more cureful heuristics for loop-invariant. Perhaps based on
number of loop carried variables or numebr of FP registers live across loopback
edge.

For 3 we would need test also benchmarks that originally exposed the problem. 
I see it was tested on povray, it would be nice the the test was repeated (and
I can probably do that if no one volunteers ;)

Honza


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[fxcoudert at gcc dot gnu dot org]

--- Comment #26 from fxcoudert at gcc dot gnu dot org  2008-02-08 14:39 
---
(In reply to comment #25)
> With external units we have a treap structure which
> holds pointers to the unit structures so that we reuse them as needed.

I haven't looked at the source code, but I can assure you that the following
code clearly shows on Windows that we leak handles for external units. It is
fact.

   character(len=1) :: string
   do
 open(10,file="foo",status="replace")
 write(10,'()')
close(10)
  end do
  end

Compile it, run it with Task manager open, and see handle count increase.


-- 


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

[Bug bootstrap/33992] [4.3 Regression] profiledbootstrap is broken

[ubizjak at gmail dot com]

--- Comment #19 from ubizjak at gmail dot com  2008-02-08 14:21 ---
The core of the problem is, that for profiled bootstrap, the call to
normalize() from do_multiply() is simply gone. Gone in the sense, that
normalize() is neither inlined at the call site, neither is called in
do_multiply(). This leads to various observed strange effects when real numbers
are processed.

  for (k = j; k < SIGSZ * 2; k += 2)
{
  unsigned long bi = b->sig[k / 2];
  if (k & 1)
bi >>= HOST_BITS_PER_LONG / 2;
  else
bi &= ((unsigned long)1 << (HOST_BITS_PER_LONG / 2)) - 1;

  u.sig[k / 2] = ai * bi;
}

> normalize (&u);
  inexact |= do_add (rr, rr, &u, 0);
}
}

Adding __attirbute__((noinline)) to protptype of normalize() is enough to fix
profiled bootstrap:

Index: real.c
===
--- real.c  (revision 132182)
+++ real.c  (working copy)
@@ -98,7 +98,7 @@
 static void clear_significand_below (REAL_VALUE_TYPE *, unsigned int);
 static bool div_significands (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *,
  const REAL_VALUE_TYPE *);
-static void normalize (REAL_VALUE_TYPE *);
+static void normalize (REAL_VALUE_TYPE *) __attribute__((noinline));

 static bool do_add (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *,
const REAL_VALUE_TYPE *, int);


So, what upsets gcc's inliner/profiler/whatever to drop the call?


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at gcc dot gnu dot org]

--- Comment #25 from jvdelisle at gcc dot gnu dot org  2008-02-08 14:26 
---
Reply to comment #23.  With external units we have a treap structure which
holds pointers to the unit structures so that we reuse them as needed  The
treap is searched first for an existing unit and returns that if it exists. 
This keys off of the unit number.  This one handle per unit.

With internal units we do not have a unit number to key off.  I could use the
address of the string itself. I have not pursued that avebue yet because it is
not the simplest approach.

I have successfully tested a patch that uses a single static unit structure for
all internal units, relying on the locking mechanism to assure that it is used
only by one operation at a time.  It works great and improves performance by
avoiding the memory allocation overhead. It uses at most only one handle.
Unfortunately, it breaks write_recursive.f90.  Recursive I/O is permitted on
internal units in F2003.

Reply to comment #24
The patch from Danny adds a new function to gthr-win32.c that does a
CloseHandle.  I will be testing this approach soon.

Regardless, I am leaning toward not locking the internal units because of some
performance gain and the need to retain recursive IO.  I will do some
comparative tests between the CloseHandle approach and the no lock approach
before proposing to the list the final patch.


-- 


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

[Bug c++/35139] g++ rejects valid code

[tim at klingt dot org]

--- Comment #1 from tim at klingt dot org  2008-02-08 14:01 ---


*** This bug has been marked as a duplicate of 35138 ***


-- 

tim at klingt dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/35138] g++ rejects valid code

[tim at klingt dot org]

--- Comment #1 from tim at klingt dot org  2008-02-08 14:01 ---
*** Bug 35139 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/35139] New: g++ rejects valid code

[tim at klingt dot org]

g++-4.3 rejects the following code:

namespace n1 {
struct foo{};
}

namespace n2 {
struct foo{};
}

using namespace n1;
using namespace n2;

template 
int run(tp const & t) {
return t.foo;
}

struct bar {
int foo;
};

int main() {
bar b;

run(b);
}

the error message is:
bug.cpp: In function ‘int run(const tp&)’:
bug.cpp:14: error: reference to ‘foo’ is ambiguous
bug.cpp:6: error: candidates are: struct n2::foo
bug.cpp:2: error: struct n1::foo

g++-4.1 and g++-4.2 accept the code, though ...


-- 
   Summary: g++ rejects valid code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug c++/35138] New: g++ rejects valid code

[tim at klingt dot org]

g++-4.3 rejects the following code:

namespace n1 {
struct foo{};
}

namespace n2 {
struct foo{};
}

using namespace n1;
using namespace n2;

template 
int run(tp const & t) {
return t.foo;
}

struct bar {
int foo;
};

int main() {
bar b;

run(b);
}

the error message is:
bug.cpp: In function ‘int run(const tp&)’:
bug.cpp:14: error: reference to ‘foo’ is ambiguous
bug.cpp:6: error: candidates are: struct n2::foo
bug.cpp:2: error: struct n1::foo

g++-4.1 and g++-4.2 accept the code, though ...


-- 
   Summary: g++ rejects valid code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug c++/35137] New: Linker error for static in-class members

[hoyninge at in dot tum dot de]

class T
{
public:
static const int STATIC_MEMBER_A = 1;
static const int STATIC_MEMBER_B = 2;
T(int x);
private:
int t;
};
T::T(int x): t(x > 0? STATIC_MEMBER_A: STATIC_MEMBER_B) {}
int main() {}

Error message:

/tmp/cc0UEe2g.o: In function `T::T(int)':
test.cpp:(.text+0x13): undefined reference to `T::STATIC_MEMBER_A'
test.cpp:(.text+0x1e): undefined reference to `T::STATIC_MEMBER_B'
/tmp/cc0UEe2g.o: In function `T::T(int)':
test.cpp:(.text+0x43): undefined reference to `T::STATIC_MEMBER_A'
test.cpp:(.text+0x4e): undefined reference to `T::STATIC_MEMBER_B'
collect2: ld returned 1 exit status

g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)


-- 
   Summary: Linker error for static in-class members
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hoyninge at in dot tum dot de


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #24 from jpr at csc dot fi  2008-02-08 12:12 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP


> This might be desirable for other reasons, but it will not fix the problem
> completely.

Yeah well, the easy way out here would be to include 
"__gthread_mutex_destroy" in the gthread-api. This should call 
CloseHandle() (or a new __gthr_win32_mutex_destroy() with a call to 
CloseHandle()) for the win32 threads and pthread_mutex_destroy() for the 
posix threads,  etc... and call the new  function in a few relevant places 
in libgfortran...


-- 


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

[Bug ada/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2008-02-08 11:23 
---
> The exception is:
> 
> TYPES.UNRECOVERABLE_ERROR : comperr.adb:398

Please post full the error message.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug ada/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[markus dot heichel at comsoft dot de]

--- Comment #4 from markus dot heichel at comsoft dot de  2008-02-08 11:27 
---
The complete output is:

> gcc -c -O adr.adb
adr.adb:19:04: warning: variable "A" is read but never assigned
adr.adb: In function 'ADR':
adr.adb:5: error: expected an SSA_NAME object
adr.adb:5: error: in statement
# A.36 = VDEF  { A.36 }
A.36 = D.375_38;
+===GNAT BUG DETECTED==+
| 4.3.0 20080201 (experimental) (i686-pc-linux-gnu) verify_ssa failed  |
| Error detected around adr.adb:5  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

adr.adb

raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398
Exit 1


-- 


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

[Bug target/35128] illegal opcode movw for mcu avr3, GCC 4.2.3 too

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-08 11:26 ---


*** This bug has been marked as a duplicate of 35073 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/35073] illegal opcode movw for mcu avr3

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-08 11:26 ---
*** Bug 35128 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Rudolf dot Leitgeb at gmx
   ||dot at


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

[Bug target/35135] unable to find a register to spill in class �GENERAL_REGS� with global registers

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-08 11:24 ---
works with -O3 (unrolled loop) on trunk, fails with 2.95, 3.3, 4.1 and 4.2 as
well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||2.95.4 3.3.3 4.1.2 4.2.2
   ||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-08 11:24:13
   date||


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #25 from belyshev at depni dot sinp dot msu dot ru  2008-02-08 
11:22 ---
Fixed.


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug ada/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[markus dot heichel at comsoft dot de]

--- Comment #2 from markus dot heichel at comsoft dot de  2008-02-08 11:16 
---
The exception is:

TYPES.UNRECOVERABLE_ERROR : comperr.adb:398


-- 


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

[Bug ada/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-08 11:11 ---
What UNRECOVERABLE_ERROR?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
Summary|[Ada] ICE caused by address |[4.3 Regression] ICE caused
   |calculation with loop   |by address calculation with
   |variable when optimization  |loop variable when
   |is on   |optimization is on
   Target Milestone|--- |4.3.0


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

[Bug ada/35136] New: [Ada] ICE caused by address calculation with loop variable when optimization is on

[markus dot heichel at comsoft dot de]

The example below raises an UNRECOVERABLE_ERROR when compiled with
optimization:

gcc -c -O adr.adb

This seems to be a regression in snapshot 4.3.0-20080201. It is working in
4.3.0-20080111 and older releases like 4.2.3.

adr.adb

pragma Extend_System(AUX_DEC);
with SYSTEM;

procedure ADR is

   function Y(E : in INTEGER) return STRING is
   begin
  return "";
   end Y;

   function X(C : in SYSTEM.ADDRESS) return STRING is
  D : INTEGER;
  for D use at C;
   begin
  return Y(D);
   end X;

   A : SYSTEM.ADDRESS;
   B : STRING := "";

begin
   for I in 0..1 loop
  B := X(SYSTEM."+"(A, I));
   end loop;
end ADR;



-- 
   Summary: [Ada] ICE caused by address calculation with loop
variable when optimization is on
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus dot heichel at comsoft dot de
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug c++/35125] Violating standards

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2008-02-08 09:01 ---
(In reply to comment #5)
> As i know C++ doesn't support VLA. Please update me if i m wrong.

That is why it is an extension. There are many things that GCC supports and ISO
C++ doesn't. Read the GCC's manual for information about extensions [1] and
about -pedantic [2].

[1] http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions
[2] http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

This is not a forum, if you need help using GCC, please ask in
[EMAIL PROTECTED] and not here. Thanks.


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[fxcoudert at gcc dot gnu dot org]

--- Comment #23 from fxcoudert at gcc dot gnu dot org  2008-02-08 08:58 
---
(In reply to comment #19)
>  I would not mind seeing a threaded example where
> this could be tested and that confirms we need to lock internal units. :)

Me too :)  I think I got confused between locking the file/string and locking
the unit. I agree that internal units don't need to be locked.

(In reply to comment #21)
> The other is to keep track of
> units assigned as internal and not create a new unit structure, but reuse the
> old. Stay tuned.

This might be desirable for other reasons, but it will not fix the problem
completely. My comment #7 shows that this problem is also present for exernal
units:

  program test
do
  open(10,file="foo",status="replace")
  write(10,'()')
  close(10)
end do
  end program test

(and watch the Handle count grow). 


-- 


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #17 from eyal at geomage dot com  2008-02-08 08:58 ---
> Using malloc instead of new does generate better code and improves performance
> slightly for me, admittedly not as much as we would like; the kernel becomes:
> (using only -O3 -S -m64 -maltivec)
> .L29:
> lvx 13,7,9
> lvx 12,3,9
> vperm 1,10,13,7
> vperm 11,9,12,8
> lvx 0,29,9
> vor 10,13,13
> vor 9,12,12
> vaddfp 1,1,11
> vaddfp 0,0,1
> stvx 0,29,9
> addi 9,9,16
> bdnz .L29
> which is as good as the vectorizer can get, iinm: peeling the loop to align 
> the
> store (and the load from the same address), treating the other two loads as
> potentially unaligned.
> To further optimize this loop we would probably want to overlap the store with
> subsequent loads using -fmodulo-sched; perhaps the new export-ddg can help 
> with
> that.

I was able to get about 20% more in one case with malloc.
I was expecting something like 2-4 times faster when the vectorization is
enabled.


-- 


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #16 from eyal at geomage dot com  2008-02-08 08:55 ---
Thanks a lot Ira, I appriciate it.
If you need the full test code with .vect file and makefiles,please let me
know.
thanks,
eyal


-- 


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

[Bug c++/35117] Vectorization on power PC

[zaks at il dot ibm dot com]

--- Comment #15 from zaks at il dot ibm dot com  2008-02-08 08:49 ---
(In reply to comment #5)
> (In reply to comment #3)
> > I think this is a dup of another bug I filed with respect of the builtin
> > operator new that getting the malloc attribute.
> Are you refering to using malloc instead of new? 
> using malloc didnt make any difference performance wise.

Using malloc instead of new does generate better code and improves performance
slightly for me, admittedly not as much as we would like; the kernel becomes:

(using only -O3 -S -m64 -maltivec)

.L29:
lvx 13,7,9
lvx 12,3,9
vperm 1,10,13,7
vperm 11,9,12,8
lvx 0,29,9
vor 10,13,13
vor 9,12,12
vaddfp 1,1,11
vaddfp 0,0,1
stvx 0,29,9
addi 9,9,16
bdnz .L29

which is as good as the vectorizer can get, iinm: peeling the loop to align the
store (and the load from the same address), treating the other two loads as
potentially unaligned.

To further optimize this loop we would probably want to overlap the store with
subsequent loads using -fmodulo-sched; perhaps the new export-ddg can help with
that.


-- 

zaks at il dot ibm dot com changed:

   What|Removed |Added

 CC||zaks at il dot ibm dot com


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