[Bug c/29282] floating point precision problem

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-29 06:42 ---
http://gcc.gnu.org/readings.html
# What Every Computer Scientist Should Know about Floating-Point Arithmetic  by
David Goldberg, including Doug Priest's supplement (PDF format)

http://www.validlab.com/goldberg/paper.pdf


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/29282] New: floating point precision problem

[wilsonymc at gmail dot com]

The floating point precision problem can be found in the following simple  ( C)
program :

***

#include 

int main(){
 float x;
 float y;
 x = 0.625;
 y = 0.425;
 printf("x = %f x = %10.2f\n", x, x);
 printf("y = %f y = %10.2f\n", y, y);
 return 0;
}

***
This program compiled with GCC 4.1.1.

The expected result is:
x = 0.625000 x =   0.63
y = 0.425000 y =   0.43

However, the actual result is:
x = 0.625000 x =   0.62 < !!
y = 0.425000 y =   0.43

Is this problem comes due to the compiler ?


-- 
   Summary: floating point precision problem
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilsonymc at gmail dot com


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

[Bug fortran/29147] Bad overflow check in DATA statements

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2006-09-29 04:55 ---
Fixed on trunk.  Although the patch would work
on 4.1, it isn't needed because I never fixed range
checking on 4.1.

Use -fno-range-check option.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.0


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

[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-09-29 04:40:41
   date||
   Target Milestone|--- |4.2.0


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

[Bug preprocessor/29276] C preprocessor run on Objective C code

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-29 04:34 ---
Someone did not read the docs correctly.
Anyways in NSException.h
the defintion for THROW should be:
# define THROW(exception...)[exception raise]


http://gcc.gnu.org/onlinedocs/gcc-4.1.1/cpp/Variadic-Macros.html#Variadic-Macros


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/29147] Bad overflow check in DATA statements

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2006-09-29 04:30 ---
I failed to not that your assertion that the error message
is misleading is incorrect.  The error message is actually
quite concise and accurate.  See section 5.2.10 of the F95
standard.

I submitted a patch that will allow you to do

gfortran -fno-range-check nonportable_code.f90


-- 


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

[Bug c++/29279] ICE

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-29 04:17 ---
t.cc:1: error: cannot initialize aggregate of type ‘const char [1]’ with a
compound literal
[EMAIL PROTECTED] gcc]$ ./cc1plus t.cc
t.cc:1: error: cannot convert ‘const char [1]’ to ‘const char [1]’ in
initialization


This works in 4.1.0 and the mainline.


-- 


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

[Bug c/29280] misleading warning for assignment used as truth construct

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-29 04:15 ---
Actually this warning is clear and I don't think it should be changed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|minor   |enhancement


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

[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-09-29 04:14 ---
(In reply to comment #3)
This is not the correct place to ask for help with knowing what is wrong with
your code, you should ask the news list: comp.lang.c++ or something closely
related.
I might look at your code this weekend bug I might have other things to do.


-- 


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

[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-29 04:05 ---
Can you try a 4.0.x build as 3.4.x is no longer being updated?


-- 


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

[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
  Component|c   |target
 GCC target triplet||arm-linux


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

[Bug fortran/29147] Bad overflow check in DATA statements

[kargl at gcc dot gnu dot org]

-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-09-29 03:26:51
   date||


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

[Bug c/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error

[sangsu at gmail dot com]

--- Comment #2 from sangsu at gmail dot com  2006-09-29 03:05 ---
and i used a gcc configuration below...

= start =
../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/
--with-headers=/ojt/kernel/linux-2.6.17/include/
= end   =
(In reply to comment #1)
> before configuring glibc...
> i had some patches, too
>  start ===
> --- gcc-3.4.1/gcc/flow.c.old2004-02-27 19:39:19.0 -0800
> +++ gcc-3.4.1/gcc/flow.c2004-08-26 07:29:46.0 -0700
> @@ -1878,6 +1878,7 @@
>   rtx set_src = SET_SRC (pc_set (BB_END (bb)));
>   rtx cond_true = XEXP (set_src, 0);
>   rtx reg = XEXP (cond_true, 0);
> + enum rtx_code inv_cond;
>   if (GET_CODE (reg) == SUBREG)
> reg = SUBREG_REG (reg);
> @@ -1886,11 +1887,13 @@
>  in the form of a comparison of a register against zero.  
>  If the condition is more complex than that, then it is safe
>  not to record any information.  */
> - if (GET_CODE (reg) == REG
> + inv_cond = reversed_comparison_code (cond_true, BB_END (bb));
> + if (inv_cond != UNKNOWN
> + && GET_CODE (reg) == REG
>   && XEXP (cond_true, 1) == const0_rtx)
> {
>   rtx cond_false
> -   = gen_rtx_fmt_ee (reverse_condition (GET_CODE (cond_true)),
> +   = gen_rtx_fmt_ee (inv_cond,
>   GET_MODE (cond_true), XEXP (cond_true, 0),
>   XEXP (cond_true, 1));
>   if (GET_CODE (XEXP (set_src, 1)) == PC)
> = end 
> (In reply to comment #0)
> > i'm a korean embedded linux engineer.
> > i'm making a cross tool-chain.
> > (gcc-3.4.1 / glibc-2.3.2 / binutils-2.15 / linux-2.6.17)
> > i used some configuration like below.
> > ../binutils-2.15/configure --target=arm-linux --prefix=/usr/local/arm
> > --disable-nls
> > ../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/
> > --with-cpu=arm9 --disable-threads --disable-shared --enable-languages=c
> >  i had some patches...
> > Č  vi sysdeps/unix/sysv/linux/arm/ioperm.c
> > Č  change "BUS_ISA" to be "CTL_BUS_ISA" lines 103 and 104
> > Č  vi Makeconfig
> > Č  change all occurrances of "O2" to "O"
> > Č  remove any occurrances of -lgcc_eh
> > Č  vi configure
> > Č  change all occurrances of "O2" to "O"
> > Č  touch sysdeps/arm/framestate.c
> > ƒå  Rm ¡Vrf nptl
> > Č  vi sysdeps/generic/wordexp.c
> > Č  /* Function called by child process in exec_comm() */
> > Č  -static void
> > Č  +static inline void
> > Č  internal_function __attribute__ ((always_inline))
> > ../glibc-2.3.6/configure --target=arm-linux --host=arm-linux
> > --prefix=/usr/local/arm/arm-linux/ --enable-add-ons=linuxthreads
> > --with-headers=/usr/src/linux/include/
> > but, i got some errors like below
> > === error start
> > =
> > gnu/java/net/natPlainDatagramSocketImpl.cc: In member function `virtual void
> > gnu::java::net::PlainDatagramSocketImpl::bind(jint, 
> > java::net::InetAddress*)': 
> > gnu/java/net/natPlainDatagramSocketImpl.cc:148: internal compiler error: in
> > arm_print_operand, at config/arm/arm.c:9810 
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://gcc.gnu.org/bugs.html> for instructions.
> > = error end
> > =
> > i've known that you got similar error and you fixed it through
> > http://gcc.gnu.org/bugzilla/.
> > so, i wonder how you fixed that bug??
> > help me plz...


-- 


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

[Bug c/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error

[sangsu at gmail dot com]

--- Comment #1 from sangsu at gmail dot com  2006-09-29 03:03 ---
before configuring glibc...
i had some patches, too

 start ===
--- gcc-3.4.1/gcc/flow.c.old2004-02-27 19:39:19.0 -0800
+++ gcc-3.4.1/gcc/flow.c2004-08-26 07:29:46.0 -0700
@@ -1878,6 +1878,7 @@
  rtx set_src = SET_SRC (pc_set (BB_END (bb)));
  rtx cond_true = XEXP (set_src, 0);
  rtx reg = XEXP (cond_true, 0);
+ enum rtx_code inv_cond;

  if (GET_CODE (reg) == SUBREG)
reg = SUBREG_REG (reg);
@@ -1886,11 +1887,13 @@
 in the form of a comparison of a register against zero.  
 If the condition is more complex than that, then it is safe
 not to record any information.  */
- if (GET_CODE (reg) == REG
+ inv_cond = reversed_comparison_code (cond_true, BB_END (bb));
+ if (inv_cond != UNKNOWN
+ && GET_CODE (reg) == REG
  && XEXP (cond_true, 1) == const0_rtx)
{
  rtx cond_false
-   = gen_rtx_fmt_ee (reverse_condition (GET_CODE (cond_true)),
+   = gen_rtx_fmt_ee (inv_cond,
  GET_MODE (cond_true), XEXP (cond_true, 0),
  XEXP (cond_true, 1));
  if (GET_CODE (XEXP (set_src, 1)) == PC)
= end 

(In reply to comment #0)
> i'm a korean embedded linux engineer.
> i'm making a cross tool-chain.
> (gcc-3.4.1 / glibc-2.3.2 / binutils-2.15 / linux-2.6.17)
> i used some configuration like below.
> ../binutils-2.15/configure --target=arm-linux --prefix=/usr/local/arm
> --disable-nls
> ../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/
> --with-cpu=arm9 --disable-threads --disable-shared --enable-languages=c
>  i had some patches...
> Č  vi sysdeps/unix/sysv/linux/arm/ioperm.c
> Č  change "BUS_ISA" to be "CTL_BUS_ISA" lines 103 and 104
> Č  vi Makeconfig
> Č  change all occurrances of "O2" to "O"
> Č  remove any occurrances of -lgcc_eh
> Č  vi configure
> Č  change all occurrances of "O2" to "O"
> Č  touch sysdeps/arm/framestate.c
> ƒå  Rm ¡Vrf nptl
> Č  vi sysdeps/generic/wordexp.c
> Č  /* Function called by child process in exec_comm() */
> Č  -static void
> Č  +static inline void
> Č  internal_function __attribute__ ((always_inline))
> ../glibc-2.3.6/configure --target=arm-linux --host=arm-linux
> --prefix=/usr/local/arm/arm-linux/ --enable-add-ons=linuxthreads
> --with-headers=/usr/src/linux/include/
> but, i got some errors like below
> === error start
> =
> gnu/java/net/natPlainDatagramSocketImpl.cc: In member function `virtual void
> gnu::java::net::PlainDatagramSocketImpl::bind(jint, 
> java::net::InetAddress*)': 
> gnu/java/net/natPlainDatagramSocketImpl.cc:148: internal compiler error: in
> arm_print_operand, at config/arm/arm.c:9810 
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> = error end
> =
> i've known that you got similar error and you fixed it through
> http://gcc.gnu.org/bugzilla/.
> so, i wonder how you fixed that bug??
> help me plz...


-- 


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

[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work

[yuanfei8077 at gmail dot com]

--- Comment #3 from yuanfei8077 at gmail dot com  2006-09-29 03:02 ---
Plesae seee Comment #2 From Kelvin 2006-09-28 23:25 [reply].

In addition 2 questions I raised in the Commet2.  I also have one more question
about the rule "bind an rvalue to a reference,
we need to let copy ctor of the class be accessible.", I found that this rule
only effective when the reference is delcared as "const &", but if we remove
keyword "const", then "no matching" happen again. 




using std::cout;
using std::endl;


class MemPool {
public:
   MemPool(){};
protected:
   MemPool(const MemPool& mempool);

};

template  class MemAllocator{

public:
   MemAllocator(MemPool& pool):m_pool(pool){}
   MemPool& get_pool() const {
   return m_pool;
   }
   template
   MemAllocator& operator=(const MemAllocator& rhs){
   m_pool = rhs.get_pool();
   return *this;
   }
   MemAllocator& operator=(const MemAllocator& rhs){
   m_pool = rhs.get_pool();
   return *this;
   }

   MemAllocator(const MemAllocator& other)
   : m_pool(other.m_pool) {}
   template
   MemAllocator(const MemAllocator& other)
   : m_pool(other.get_pool()) {}

private:
   MemAllocator();
//  MemAllocator(const MemAllocator&);
   MemPool &m_pool;

};


template  class tdat_hash_map {
public:
   typedef _AllocType _Alloc;

   static void func(const _Alloc&) {};
   tdat_hash_map(const _Alloc&); // there will be error if const is removed

   _Alloc malloc;
private:
   tdat_hash_map();
};

class CacheManager {
public:

   typedef tdat_hash_map > Map;

   Map caches;
   MemPool pool;
   CacheManager():caches(MemAllocator(pool)){};

};


-- 

yuanfei8077 at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c/29281] New: natPlainDatagramSocketImpl.cc:148: internal compiler error

[sangsu at gmail dot com]

i'm a korean embedded linux engineer.

i'm making a cross tool-chain.

(gcc-3.4.1 / glibc-2.3.2 / binutils-2.15 / linux-2.6.17)

i used some configuration like below.

../binutils-2.15/configure --target=arm-linux --prefix=/usr/local/arm
--disable-nls

../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/
--with-cpu=arm9 --disable-threads --disable-shared --enable-languages=c

 i had some patches...

Č  vi sysdeps/unix/sysv/linux/arm/ioperm.c
Č  change "BUS_ISA" to be "CTL_BUS_ISA" lines 103 and 104

Č  vi Makeconfig
Č  change all occurrances of "O2" to "O"
Č  remove any occurrances of -lgcc_eh
Č  vi configure
Č  change all occurrances of "O2" to "O"
Č  touch sysdeps/arm/framestate.c
ƒå  Rm ¡Vrf nptl

Č  vi sysdeps/generic/wordexp.c
Č  /* Function called by child process in exec_comm() */
Č  -static void
Č  +static inline void
Č  internal_function __attribute__ ((always_inline))

../glibc-2.3.6/configure --target=arm-linux --host=arm-linux
--prefix=/usr/local/arm/arm-linux/ --enable-add-ons=linuxthreads
--with-headers=/usr/src/linux/include/

but, i got some errors like below

=== error start
=
gnu/java/net/natPlainDatagramSocketImpl.cc: In member function `virtual void
gnu::java::net::PlainDatagramSocketImpl::bind(jint, java::net::InetAddress*)': 

gnu/java/net/natPlainDatagramSocketImpl.cc:148: internal compiler error: in
arm_print_operand, at config/arm/arm.c:9810 

Please submit a full bug report,

with preprocessed source if appropriate.

See http://gcc.gnu.org/bugs.html> for instructions.
= error end
=

i've known that you got similar error and you fixed it through
http://gcc.gnu.org/bugzilla/.

so, i wonder how you fixed that bug??

help me plz...


-- 
   Summary: natPlainDatagramSocketImpl.cc:148: internal compiler
error
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sangsu at gmail dot com


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

[Bug target/28617] ___divti3 and ___umodti3 undefined for -m64 on powerpc-apple-darwin8

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2006-09-29 01:29 ---
This should be fixed by the last checkin.


-- 


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

[Bug target/28617] ___divti3 and ___umodti3 undefined for -m64 on powerpc-apple-darwin8

[mrs at gcc dot gnu dot org]

--- Comment #3 from mrs at gcc dot gnu dot org  2006-09-29 01:21 ---
Subject: Bug 28617

Author: mrs
Date: Fri Sep 29 01:21:14 2006
New Revision: 117296

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117296
Log:
PR target/28617
* config/rs6000/rs6000.h [IN_LIBGCC2] (TARGET_POWERPC64): Define
to 1 when __ppc64__ is defined.
* config/rs6000/t-darwin (LIB2FUNCS_EXTRA): Add ppc64-fp.c and
darwin-64.c.
* config/rs6000/ppc64-fp.c: Also compile when __ppc64__ is defined.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/ppc64-fp.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/rs6000/t-darwin


-- 


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

[Bug c/29280] New: misleading warning for assignment used as truth construct

[elanthis at awesomeplay dot com]

For code of the form:
if (var = 0)
gcc recommends adding parentheses around the construct.  This is intended to
disambiguate code of the form:
if (ptr = get_ptr())
by coercing people to write it in the form:
if ((ptt = get_ptr()) != NULL)

However, in many cases, especially for novice C developers, the code was
intended to mean:
if (ptr == get_ptr())
or
if (var == 0)

I'm submitting this bug report because I just saw yet another case of a novice
developer posting on a forum that he had been trying to get some code to work,
and the code he posted included:
if (( var = 0 ))
I asked and found that he had done what the gcc warning had kindly suggested,
not really understanding what the warning meant.

The warning is "warning: suggest parentheses around assignment used as truth
value"

I suggest several possibilities to improve the situation.  The first is to
simply alter or expand the warning slightly.  Perhaps something like, "warning:
use == for testing equality; suggest parentheses around assignment used as
truth value"

The second is to use two separate warning message with some heuristics to
determine which to prefer.  For example, an assignment to a constant is very
rarely used as a truth value.  Code of the form 'if ( var = 0 )' should produce
a warning that == must be used to test equality.  I won't try to make concrete
suggestions on the best set of heuristics for these cases, but that one at
least is obvious.  I would wager that using any non-function expression in an
assignment rvalue as a truth value is very rare; that is, 'if ( (foo = bar) !=
0 )' is far rarer than 'if ( (foo = baz()) != 0 )'.


-- 
   Summary: misleading warning for assignment used as truth
construct
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: elanthis at awesomeplay dot com


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

[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)

[lopezibanez at gmail dot com]

--- Comment #5 from lopezibanez at gmail dot com  2006-09-29 00:53 ---
(In reply to comment #4)
> Not so surprising if you check gcc/c-typeck.c line 3980. The warning is not
> conditionalised to any option. What is the criteria for a warning to be 
> emitted
> always or be conditional to a given option?
> 

Argh! I meant line 4100 (although perhaps it is the same warning, not sure).


-- 


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

[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)

[lopezibanez at gmail dot com]

--- Comment #4 from lopezibanez at gmail dot com  2006-09-29 00:37 ---
Not so surprising if you check gcc/c-typeck.c line 3980. The warning is not
conditionalised to any option. What is the criteria for a warning to be emitted
always or be conditional to a given option?


-- 


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

[Bug fortran/25818] Problem with handling optional and entry master arguments

[kargl at gcc dot gnu dot org]

--- Comment #8 from kargl at gcc dot gnu dot org  2006-09-29 00:30 ---
Paul, Jakub,

Is the patch in comment #7 considered to be the right approach?
I tried applying to my local tree, but a few chunks were rejected.


-- 


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

[Bug c++/29279] New: ICE

[philippe at fornux dot com]

const char nullstr[1] = (const char [1]) {0};

int main()
{
}


-- 
   Summary: ICE
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe at fornux dot com
 GCC build triplet: Mingw32


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

[Bug fortran/29147] Bad overflow check in DATA statements

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2006-09-29 00:25 ---
(In reply to comment #1)
> Created an attachment (id=12299)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12299&action=view) [edit]
> Legacy code example
> 
> Compiles fine with every other compiler out there.
> 

That's because every other compiler out there is broken :-)

The standard is quite clear that the BOZ is converted to an
integer with the kind type with the largest decimal range.
In your case that integer is kind=8, and  Z'' = 4294967295
which over flows the range of an integer(kind=4) constant.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug middle-end/29256] [4.2 regression] loop performance regression

[rakdver at gcc dot gnu dot org]

--- Comment #16 from rakdver at gcc dot gnu dot org  2006-09-28 23:48 
---
Patch for the induction variable selection (that however does not fix the
problem with offsetted addressing modes not being created after unrolling):

http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01308.html


-- 


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

[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2006-09-28 23:36 
---
Another thought occurs to me.  With formatted stream I/O the newline is handled
automatically for the user.  However, there is nothing to say someone would not
want to use unformatted stream I/O to write human readable files.  In that
case, you would want the result of newline to give the /r/n or /n on the
respective systems.

Based on this thinking, the translation, if any, should be done for unformatted
I/O and only when the NEWLINE function is explicitly used.

Clealy we have a case where the standard may not be all that clear.


-- 


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

[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work

[yuanfei8077 at gmail dot com]

--- Comment #2 from yuanfei8077 at gmail dot com  2006-09-28 23:25 ---
Subject: Re:  Rule that binding rvalue to a refernce need a copy ctor don't
work

Hi Andrew,

You are right, I am omitting the code, however, my question is:

1)
> t.cc:38: error: 'MemAllocator::MemAllocator() [with Type = int]' is
> private
> t.cc:49: error: within this context

However, MemAllocator is only invoked by class data member cache's
intialization list, and MemAllocator's copy constructor is already
provided, so you mean I am forced to offer default constructor too to
make it pass, right ?

2)
> There is no
> tdat_hash_map(_Alloc&) in the sources.

>::tdat_hash_map(MemAllocator)main.cpp:49: note: candidates are:
tdat_hash_map<_AllocType>::tdat_hash_map() [with _AllocType =
MemAllocator]
main.cpp:42: note: tdat_hash_map
>::tdat_hash_map(const tdat_hash_map >&)

But from the original error output, comiler have added a default
tdat_hash_map in line 42, and its format is same as what you added to
make "no matching" error disappear.  Can you explain explain why the
default can't work ?


Thanks for your help!

-Kelvin




On 28 Sep 2006 13:39:16 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-28 13:39 
> ---
> There is no
> tdat_hash_map(_Alloc&) in the sources.
> Adding one makes it get past that error and then we get:
> t.cc: In constructor 'tdat_hash_map<_AllocType>::tdat_hash_map(const
> _AllocType&) [with _AllocType = MemAllocator]':
> t.cc:64:   instantiated from here
> t.cc:38: error: 'MemAllocator::MemAllocator() [with Type = int]' is
> private
> t.cc:49: error: within this context
>
>
> So this is invalid still.
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> 
> Status|UNCONFIRMED |RESOLVED
> Resolution||INVALID
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2006-09-28 23:23 
---
Please note that with formatted stream I/O we implicitly write a /n or /r/n in
the next_record_w () function in transfer.c depending on the system.  I think
this meets the intent.

Now an issue I see is what if we want to explicitly write a /n on this system? 
There would be no way to do that if we translate it to /n/r.  I am not sure the
intent of the committee was to restrict this in this way, but allow it in the
case of formatted end of record.

I have not tried this, but if I write out a formatted string with one character
/n I wonder if we we get /n/r/n with current gfortran.  

I am not agreeing or diagreeing here.  You have raised a good question here.


-- 


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

[Bug libgcj/29278] [ecj] libjava Makefile has -j bug

[tromey at gcc dot gnu dot org]

-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-09-28 23:03:51
   date||


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

[Bug libgcj/29278] New: [ecj] libjava Makefile has -j bug

[tromey at gcc dot gnu dot org]

I believe the libjava Makefile.am on the gcj-eclipse branch
has a bug with -j builds, where it may try to build the CNI
header files multiple times.


-- 
   Summary: [ecj] libjava Makefile has -j bug
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
OtherBugsDependingO 28067
 nThis:


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

[Bug fortran/19261] continuation character illegal as first non-blank character in statement

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2006-09-28 22:40 
---
I have this one fixed and will combine it with the pathes for 19260 and 19262.


-- 


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

[Bug fortran/29277] New: Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms

[tobias dot burnus at physik dot fu-berlin dot de]

See http://gcc.gnu.org/ml/fortran/2006-09/msg00415.html

Brooks Moses wrote:

when a file is connected for stream access, the runtime library could very
easily do a s/\n/\r\n/ on the output stream before writing it to the file. In
fact, if we consider \r\n to be a record marker (on a given system), and we do
wish to implement the behavior described in this paragraph [10.6.3] then it
would be required to do so.

Actually, now that I read section 9.2.2.3 (and particularly note 9.9) on the
Fortran 2003 Standard, I'm pretty sure it was the intent of the standard
committee that this sort of substitution be done. Note 9.9 states:

There may be some character positions in the file that do not correspond
to characters written; this is because on some processors a record
marker may be written to the file as a carriage-return/linefeed
or other sequence. The means of determining the position in a file
connected for stream access is via the POS= specifier in an INQUIRE
statement (9.9.1.21).

Note, in particular, that this whole matter only applies to _formatted_ stream
files -- that is, files which are expected to contain human-readable text that
could be edited in a text editor. For unformatted stream files -- which are the
only ones that should be containing "binary" data that would be corrupted by
the substitution -- this doesn't apply, and no substitution would be made.

Thus, I think it's pretty clear that NEW_LINE should return ACHAR(10), and that
for formatted stream-access files, the runtime library should convert that
character to the appropriate system-specific line-ending string when writing to
files. (This substitution would not be a regression against g77, because files
opened for stream access do not exist in g77 code, and the substitution would
not be made for non-stream files.)


-- 
   Summary: Formated stream output: Translate "\n" / achar(10) into
"\r\n" on some platforms
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de


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

[Bug fortran/28813] gfortran.dg/direct_io_6.f90 can exhaust system disk space

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2006-09-28 22:39 
---
Closing, test not needed.


-- 

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=28813

[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2006-09-28 22:34 
---
(In reply to comment #7)
> Changing main() in ctesti.c  to start with:
> int main(int argc, char** argv) {
>   setvbuf(stdout, NULL, _IOLBF, 0);
> 
> fixes the redirection problem.

After some more testing, this fix doesn't work in all cases (e.g. in a shell of
MSYS window). I'm closing this PR: after all, this is not a bug in the
compiler, mixed-languages code is supposed to correctly flush both I/O systems
after operations. I would have liked to provide a workaround, only there
doesn't appear to be anythink general and robust enough.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/29276] C preprocessor run on Objective C code

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-28 22:15 ---
([ will never make a valid token even in Objective-C mode.


-- 


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

[Bug preprocessor/29276] New: C preprocessor run on Objective C code

[roberthensing at hotmail dot com]

Everytime I try to compile the libFoundation sources the preprocessor complains
with error messages like these:

NSObject.m:382:1: error: pasting "(" and "[" does not give a valid
preprocessing token
NSObject.m:513:1: error: pasting "(" and "[" does not give a valid
preprocessing token

I had to preprocess the source with the -x objective-c flags, forcing cpp to
process the file in Objective C mode and it worked fine.

I would have attached the preprocessed file, if there would have been an option
to make the preprocessor only include files and not expand macros but I
couldn't find it in your documentation. I might have overlooked it.

Sources can be found here:
http://prdownloads.sourceforge.net/libfoundation/libFoundation-0.9.0.tar.gz?download

GCC was invoked like this:
gcc -fPIC -fgnu-runtime -I.. -g -O2 -fobjc-exceptions -Wall -DDEBUG -c
NSObject.m -o shared_obj/NSObject.o

Adding the -x objective-c flags to the gcc command line did not work.


-- 
   Summary: C preprocessor run on Objective C code
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roberthensing at hotmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/29206] [4.2 regression] gcj-dbtool segfaults

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2006-09-28 
20:53 ---
Subject: Re:  [4.2 regression] gcj-dbtool segfaults

> Starting program: /home/doko/gcc/4.2/install/usr/bin/gcj-dbtool-4.2 -n foo.db
> 64
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 18291)]
> [New Thread 32769 (LWP 20685)]
> [New Thread 16386 (LWP 20790)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 18291)]
> 0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1
> (gdb) bt
> #0  0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1

The following patch introduced _Unwind_GetIPInfo:

2006-02-27  Jakub Jelinek  <[EMAIL PROTECTED]>

PR other/26208
...

Dave


-- 


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

[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2006-09-28 19:36 ---
This should be fixed by the patch I just committed.
Note, you'll see two gfortran testsuite programs
fail because your version of mpfr is too old.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/29206] [4.2 regression] gcj-dbtool segfaults

[debian-gcc at lists dot debian dot org]

--- Comment #3 from debian-gcc at lists dot debian dot org  2006-09-28 
19:31 ---
attached the stacktrace for arm-linux-gnu

  Matthias

(gdb) run
Starting program: /home/doko/gcc/4.2/install/usr/bin/gcj-dbtool-4.2 -n foo.db
64
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 18291)]
[New Thread 32769 (LWP 20685)]
[New Thread 16386 (LWP 20790)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 18291)]
0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1
(gdb) bt
#0  0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1
#1  0x40b988c0 in _Jv_StackTrace::UnwindTraceFn (context=0xbfffebcc,
state_ptr=)
at ../../../src/libjava/stacktrace.cc:141
#2  0x41bf6a04 in _Unwind_Backtrace () from /lib/libgcc_s.so.1
#3  0x40b987cc in _Jv_StackTrace::GetStackTrace () at
../../../src/libjava/stacktrace.cc:170
#4  0x40bd9bd0 in java::lang::VMThrowable::fillInStackTrace () at
../../../src/libjava/java/lang/natVMThrowable.cc:33
#5  0x40f9aee4 in java.lang.Throwable.fillInStackTrace()java.lang.Throwable
(this=0xbfffebcc)
at ../../../src/libjava/classpath/java/lang/Throwable.java:498
#6  0x40f9a8d4 in java.lang.Throwable.Throwable(java.lang.String)
(this=0x41ef2220, message=0x41f6ed98)
at ../../../src/libjava/classpath/java/lang/Throwable.java:159
#7  0x40f846d8 in java.lang.Exception.Exception(java.lang.String)
(this=0xbfffebcc, s=0xbfffebac)
at ../../../src/libjava/classpath/java/lang/Exception.java:77
#8  0x40f8219c in
java.lang.ClassNotFoundException.ClassNotFoundException(java.lang.String)
(this=0xbfffebcc, s=0xbfffebac)
at ../../../src/libjava/classpath/java/lang/ClassNotFoundException.java:83
#9  0x40fc7870 in
java.net.URLClassLoader.findClass(java.lang.String)java.lang.Class
(this=0x41edb2d8, className=0x41f0fb90)
at ../../../src/libjava/java/net/URLClassLoader.java:1080
#10 0x40bfdb48 in
gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)java.lang.Class
(this=0xbfffebcc, name=0x41f0fb90)
at ../../../src/libjava/gnu/gcj/runtime/BootClassLoader.java:55
#11 0x40bd9788 in java::lang::VMClassLoader::loadClass (name=0x41f0fb90,
resolve=0 '\0')
at ../../../src/libjava/java/lang/natVMClassLoader.cc:208
#12 0x40bd2d90 in _Jv_FindClass (name=0x41f0d730, loader=0x0) at
../../../src/libjava/java/lang/natClassLoader.cc:407
#13 0x40bd1a40 in java::lang::Class::forName (className=0x41f6ee88,
initialize=1 '\001', loader=0x0)
at ../../../src/libjava/java/lang/natClass.cc:88
#14 0x40bf8f90 in
gnu.gcj.convert.BytesToUnicode.getDecoder(java.lang.String)gnu.gcj.convert.BytesToUnicode
(encoding=0x41edcaf0)
at ../../../src/libjava/gnu/gcj/convert/BytesToUnicode.java:101
#15 0x40bd7a40 in java::lang::String::init (this=0x3, bytes=0x41efad30,
offset=0, count=2, encoding=0x41edcaf0)
at ../../../src/libjava/java/lang/natString.cc:490
#16 0x40f91210 in java.lang.String.String(byte[], int, int) (this=0x41f6eeb8,
data=0x41efad30, offset=0, count=2)
at ../../../src/libjava/java/lang/String.java:345
#17 0x40b83f24 in JvConvertArgv (argc=3, argv=0xa398) at
../../../src/libjava/prims.cc:953
#18 0x40b84e58 in _Jv_RunMain (vm_args=0x0, klass=0x16460, name=0x0, argc=4,
argv=0xba64, is_jar=false)
at ../../../src/libjava/prims.cc:1537
#19 0x40b85190 in _Jv_RunMain (klass=0xbfffebac, 
name=0x41714e90
"(d���Ah\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@h\036���@"...,
argc=1085821328, argv=, 
is_jar=false) at ../../../src/libjava/prims.cc:1597
#20 0x40b851bc in JvRunMain (klass=0xbfffebcc, argc=1097944720, argv=0x0) at
../../../src/libjava/prims.cc:1603
#21 0x41c14e44 in __libc_start_main () from /lib/libc.so.6
#22 0x41c14e44 in __libc_start_main () from /lib/libc.so.6
Previous frame identical to this frame (corrupt stack?)


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

 CC||pb at gcc dot gnu dot org


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

[Bug target/29206] [4.2 regression] gcj-dbtool segfaults

[debian-gcc at lists dot debian dot org]

--- Comment #2 from debian-gcc at lists dot debian dot org  2006-09-28 
19:30 ---
(In reply to comment #1)
> Either show that it is a regression, or dont put the regression marker in the
> subject.

rechecked, that it is a regression on hppa-linux-gnu, compared to 4.1.2 SVN.

  Matthias


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

  Known to fail||4.2.0
  Known to work||4.1.2
Summary|gcj-dbtool segfaults|[4.2 regression] gcj-dbtool
   ||segfaults


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

[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2006-09-28 18:48 ---
Crap.  Re-open.

mpfr_subnormalized() first appeared in 2.2.0.  I'll fix this in
a few minutes.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug other/29271] Incorrect -fdump-rtl-sched documentation

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-28 18:45 ---
-fdump-rtl-sched should be -fdump-rtl-sched1.
The numbering system is a different story and is wrong for most rtl dumps now
because someone forgot to update them when they changed the numbering system
and/or added a pass.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-09-28 18:45:13
   date||


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

[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2006-09-28 18:40 ---
gfortran will work with the buggy mpfr.  You simply will not
get the bug fixes for 27021 and 28276.

You have not installed gmp-4.1.4 as distributed by the 
GMP developers.  The mpfr.h header file in the version of
mpfr included in gmp-4.1.4 does included

/* Define MPFR version number */
#define MPFR_VERSION_MAJOR 2
#define MPFR_VERSION_MINOR 1
#define MPFR_VERSION_PATCHLEVEL 1

In fact it does not include any of these.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug other/29271] Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document

[dberlin at dberlin dot org]

--- Comment #1 from dberlin at gcc dot gnu dot org  2006-09-28 18:39 ---
Subject: Re:  New: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document

This is because on your platofrm, sched1 doesn't run.


On 28 Sep 2006 15:51:05 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
> There are
>
> @itemx -fdump-rtl-sched2
> @opindex dR
> @opindex fdump-rtl-sched2
> Dump after the second scheduling pass, to @[EMAIL PROTECTED]
>
> @item -dS
> @itemx -fdump-rtl-sched
> @opindex dS
> @opindex fdump-rtl-sched
> Dump after the first scheduling pass, to @[EMAIL PROTECTED]
>
> in invoke.texi. But I got
>
> [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc --version
> gcc (GCC) 4.2.0 20060913 (experimental) [trunk revision 116922]
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched -S slow.c
> cc1: error: unrecognized command line option "-fdump-rtl-sched"
> [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched2 -S slow.c
> [EMAIL PROTECTED] slow-9]$ ls -l slow.c.149r.sched2
> -rw-r--r--  1 hjl hjl 16119 Sep 28 08:44 slow.c.149r.sched2
>
>
> --
>Summary: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2
> document
>Product: gcc
>Version: 4.2.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: other
> AssignedTo: unassigned at gcc dot gnu dot org
> ReportedBy: hjl at lucon dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29271
>
>


-- 


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

[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code

[dnovillo at gcc dot gnu dot org]

--- Comment #3 from dnovillo at gcc dot gnu dot org  2006-09-28 18:32 
---

Excerpts from IRC session with jakub discussing this:

13:28   1grow ();
13:28   2node = pool;
13:28   3D.1928 = node->next;
13:28   4pool = D.1928;
13:28   5foo = (struct Foo *) node;
13:28   6foo->a = 0;
13:28   7foo->b = -1;
13:28   8node = (struct Node *) foo;   <- redundant. node ==
foo already.
13:28   9node->next = D.1928;  <- redundant.
node->next == D.1928 already
13:28  10pool = node;  <- redundant. node ==
pool already.
13:28  11return foo->a;
13:33  line 9 is not redundant, because node->next occupies the same
memory as foo->a and foo->b
13:34  I think we have 2 options with this optimization
13:35  1) for each memcpy etc. operand, look through all handled
components and if it is an actual VAR_DECL, we can surely optimize it, with the
native alias set
13:36  but if it is a pointer, we can't be sure
13:37  now, either we figure out some way how to express that operation
in an alias friendly way if it is a pointer, or we just bail and don't optimize
13:37  but, my point was that i don't see where the RTL optimizers
may be screwing up.  what's the exact operation that they remove that they
shouldn't have?
13:37  it all looks removable to me.
13:39  RTL optimizers remove the node->next = D.1928 line
13:40  which means 1) pool->next is in the end 0 rather than old
pool->next
13:40  and 2) 0 is returned rather than (int) pool->next
13:40  but D.1928 and node->next have the same value according to the
tree dump.  or am i misreading something?
14:03  foo == node, so foo->a and node->next occupy the same memory
14:03  oh, crap.
14:03  and eventhough those 2 have aliasing incompatible types, the use
of memcpy makes it ok
14:03  i had missed that.
14:04  guess I'll now write just a quick patch to only do it for
VAR_DECLs and components thereof
14:05  so that the bug is fixed and we can then keep discussing how even
pointers can be safely optimized
14:05  so, going back to not apply this on pointers then?
14:05  yeah, for now that would be the safe approach.
14:10/* If var is a VAR_DECL or a component thereof,
14:10   we can use its alias set, otherwise we'd need to make
14:10   sure we go through alias set 0.  */
14:10inner = srcvar;
14:10while (handled_component_p (inner))
14:10  inner = TREE_OPERAND (inner, 0);
14:10if (TREE_CODE (inner) != VAR_DECL)
14:10  return 0;
14:11  or should I use SSA_VAR_P (inner) instead?
14:12  I guess at least PARM_DECL or RESULT_DECL would be ok, not sure
about SSA names
14:22  the reason we don't screw up in the trees is the presence of
points-to information, most likely.  i got tricked because i wasn't following
who was pointing to who.
14:22  the store foo->a changes node->next.
14:23  bah.
14:23  RTL misses that because the stores have different alias sets.
14:23  the transformation we do on trees is invalid for RTL because
we don't keep points-to info in RTL, only type info.
14:23  the Real Fix would tag the stores so that gimple->RTL changes
the alias sets.
14:24  something along the lines of what you suggest may work.
14:26  yeah, now to find a way to force the alias set...


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.2.0   |---


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

[Bug fortran/29275] New: fortran added to language build list even when known buggy version of mpfr found

[lucier at math dot purdue dot edu]

Configured with

 ../configure --prefix=/pkgs/gcc-test --with-gmp=/pkgs/gmp-4.1.4/
--with-mpfr=/pkgs/gmp-4.1.4/

The following messages come up during configure:

checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... buggy version of MPFR detected
checking for any version of mpfr.h... yes
The following languages will be built: c,c++,fortran,java,objc
*** This configuration is not supported in the following subdirectories:
 target-libmudflap target-libada gnattools
(Any other directories should still work fine.)

In /pkgs/gmp-4.1.4/include/mpfr.h we find

/* Define MPFR version number */
#define MPFR_VERSION_MAJOR 2
#define MPFR_VERSION_MINOR 1
#define MPFR_VERSION_PATCHLEVEL 1

which is indeed insufficient to build gfortran, but gfortran is still
configured in and "make bootstrap" fails with

/Users/gcc-test/programs/gcc/mainline/objdir-64/./prev-gcc/xgcc
-B/Users/gcc-test/programs/gcc/mainline/objdir-64/./prev-gcc/
-B/pkgs/gcc-test/powerpc-apple-darwin8.7.0/bin/ -c   -g -O2 -mdynamic-no-pic
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute -Werror -fno-common  
-DHAVE_CONFIG_H -I. -Ifortran -I../../gcc -I../../gcc/fortran
-I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I/pkgs/gmp-4.1.4//include -I/pkgs/gmp-4.1.4//include
-I../../gcc/../libdecnumber -I../libdecnumber../../gcc/fortran/arith.c -o
fortran/arith.o
cc1: warnings being treated as errors
../../gcc/fortran/arith.c: In function 'gfc_check_real_range':
../../gcc/fortran/arith.c:445: warning: implicit declaration of function
'mpfr_subnormalize'
make[3]: *** [fortran/arith.o] Error 1

[descartes:gcc/mainline/objdir-64] gcc-test% cat ../LAST_UPDATED 
Thu Sep 28 09:43:25 EDT 2006
Thu Sep 28 13:43:25 UTC 2006 (revision 117281M)


-- 
   Summary: fortran added to language build list even when known
buggy version of mpfr found
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
 GCC build triplet: powerpc-apple-darwin8.7.0
  GCC host triplet: powerpc-apple-darwin8.7.0
GCC target triplet: powerpc-apple-darwin8.7.0


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

[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2006-09-28 18:17 ---
Created an attachment (id=12352)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12352&action=view)
gcc42-pr29272.patch

Untested patch to just bail for non-vars.


-- 


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

[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2006-09-28 17:57 ---
I think after we want to look through handled_component_p's of destvar/srcvar
(in fold_builtin_memory_op) resp. var (in fold_builtin_memset) and see if
inside is a VAR_DECL or not.  If it is a VAR_DECL, then I believe the
optimization is always safe, if it is INDIRECT_REF of a pointer, then it would
be only safe if we can make the read resp. write use forcibly alias set 0.
If we e.g. made a copy of the pointer and set DECL_POINTER_ALIAS_SET on it,
would that work and not be optimized out?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org,
   ||dnovillo at redhat dot com


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

[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.2.0


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

[Bug c/29274] 4.1, 4.2 (possibly 4.0?) not using mulsidi3

[eplondke at gmail dot com]

--- Comment #2 from eplondke at gmail dot com  2006-09-28 16:46 ---
Forgot to say: I'm seeing this on an ARM cross-compilation.


-- 


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

[Bug c/29274] 4.1, 4.2 (possibly 4.0?) not using mulsidi3

[eplondke at gmail dot com]

--- Comment #1 from eplondke at gmail dot com  2006-09-28 16:45 ---
Created an attachment (id=12351)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12351&action=view)
Test case showing mulsidi problem

Multimedia processing

It's not self-running, but you can see plainly from the assembly output.

If you want a self-running test I can modify it a bit.


-- 


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

[Bug c/29274] New: 4.1, 4.2 (possibly 4.0?) not using mulsidi3

[eplondke at gmail dot com]

GCC 4.x tree optimization decides to put int values into long long int
temporaries.  When RTL expansion comes around, the expander sees only a DImode
multiply and so generates three SImode multiplies to deal with the problem.

GCC 3.x sees that the source values are SImode and uses mulsidi3 to generate
32x32->64 multiplies, which are much more efficient.  It also picks up the
accumulation.

(using -O3 for all compilations)

GCC 3.4 has an 84-byte stack frame, and a body of 372 instructions.
GCC 4.1 has a 1416-byte stack frame, and a body of 1668 instructions.
GCC 4.2 has a 1320-byte stack frame, and a body of 1565 instructions.


-- 
   Summary: 4.1, 4.2 (possibly 4.0?) not using mulsidi3
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eplondke at gmail dot com
  GCC host triplet: x86_64-suse-linux
GCC target triplet: arm-unkown-elf


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

[Bug c++/29185] inconsistent warning: deleting array

[sebor at roguewave dot com]

--- Comment #8 from sebor at roguewave dot com  2006-09-28 16:16 ---
The EDG guys don't think this is worth spending the committee's time on so I
won't
be proposing any change to the standard. Issuing just a warning rather than an
error is good enough for me.

Also, I opened bug 29273 to remove the error from the dynamic_cast expression
with an array argument since that one is well-formed as well (see comment 2),
according to the same paragraph.


-- 


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

[Bug c++/29273] New: error on dynamic_cast(array)

[sebor at roguewave dot com]

Gcc gives an error for the dynamic_cast below. During the discussion of bug
29185 with EDG it turned out that according to 5, p8, the code is well-formed
and should not be diagnosed.

$ cat t.cpp && gcc t.cpp
struct A { virtual ~A () { } };
struct B: A { } b [1];

void foo ()
{
dynamic_cast(b);
}
t.cpp: In function 'void foo()':
t.cpp:6: error: cannot dynamic_cast 'b' (of type 'struct B [1]') to type
'struct B*' (source is not a pointer)


-- 
   Summary: error on dynamic_cast(array)
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


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

[Bug middle-end/29272] New: [4.2 Regression] memcpy optimization causes wrong-code

[rguenth at gcc dot gnu dot org]

With the following testcase lowering memcpy to pointer assignment causes
wrong alias information to be generated.

struct Foo {
  int a;
  int b;
};
struct Node;
struct Node {
  struct Node *next;
};
struct Node *pool;
void grow (void)
{
  char *mem = __builtin_malloc (4096);
  struct Node *node = (struct Node *)mem;
  struct Foo *foo;
  __builtin_memcpy (&node->next, &pool, sizeof(struct Node*));
  pool = node;
} 
static inline void *alloc_one (void)
{ 
  struct Node *node = pool;
  __builtin_memcpy (&pool, &node->next, sizeof(struct Node*));
  return node;
}
static inline void dealloc_one (void *p)
{
  struct Node *node = p;
  __builtin_memcpy (&node->next, &pool, sizeof(struct Node*));
  pool = node;
}
int bar(void)
{
  grow();
  struct Foo* foo = alloc_one();
  foo->a = 0;
  foo->b = -1;
  dealloc_one (foo);
  return foo->a;
}

while we have in .optimized

:
  grow ();
  node = pool;
  D.1928 = node->next;
  pool = D.1928;
  foo = (struct Foo *) node;
  foo->a = 0;
  foo->b = -1;
  node = (struct Node *) foo;
  node->next = D.1928;
  pool = node;
  return foo->a;

asm generates:

bar:
.LFB5:
subq$8, %rsp
.LCFI1:
callgrow
movqpool(%rip), %rax
movl$0, (%rax)
movl$-1, 4(%rax)
xorl%eax, %eax
addq$8, %rsp
ret

which is wrong.


-- 
   Summary: [4.2 Regression] memcpy optimization causes wrong-code
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: wrong-code, alias
  Severity: blocker
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug other/29271] New: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document

[hjl at lucon dot org]

There are

@itemx -fdump-rtl-sched2
@opindex dR
@opindex fdump-rtl-sched2
Dump after the second scheduling pass, to @[EMAIL PROTECTED]

@item -dS
@itemx -fdump-rtl-sched
@opindex dS
@opindex fdump-rtl-sched
Dump after the first scheduling pass, to @[EMAIL PROTECTED]

in invoke.texi. But I got

[EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc --version
gcc (GCC) 4.2.0 20060913 (experimental) [trunk revision 116922]
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched -S slow.c
cc1: error: unrecognized command line option "-fdump-rtl-sched"
[EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched2 -S slow.c
[EMAIL PROTECTED] slow-9]$ ls -l slow.c.149r.sched2
-rw-r--r--  1 hjl hjl 16119 Sep 28 08:44 slow.c.149r.sched2


-- 
   Summary: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2
document
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org


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

[Bug driver/29270] "--" does not end option parsing

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2006-09-28 15:04 ---
Subject: Re:  "--" does not end option parsing

On Thu, 28 Sep 2006, pinskia at gcc dot gnu dot org wrote:

> Hmm, one problem is that we need to know when we should pass -- on to cc1, 
> etc.
> also.  For an example:
> 
> gcc t.c -- -l.c
> 
> is that -l.c a c source or a library for ld to have at and how do we invoke ld
> then:
> with "-- -l.c" or just "-l.c"

It's a source file - everything after -- should be a source or object file 
according to the suffix.  -lfoo would mean that an object file called 
literally -lfoo is to be linked, not libfoo.a.  You could either pass -- 
to ld or change -lfoo to ./-lfoo.


-- 


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

[Bug middle-end/29269] missing documentation for "vcond" (vector conditional operation)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-28 15:00 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||documentation
   Last reconfirmed|-00-00 00:00:00 |2006-09-28 15:00:18
   date||


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

[Bug driver/29270] "--" does not end option parsing

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-28 14:59 ---
Hmm, one problem is that we need to know when we should pass -- on to cc1, etc.
also.  For an example:

gcc t.c -- -l.c

is that -l.c a c source or a library for ld to have at and how do we invoke ld
then:
with "-- -l.c" or just "-l.c"


-- 


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

[Bug middle-end/29256] [4.2 regression] loop performance regression

[rakdver at gcc dot gnu dot org]

--- Comment #15 from rakdver at gcc dot gnu dot org  2006-09-28 14:50 
---
(In reply to comment #8)
>   D.1563 = -&a;
>   MEM[base: (int *) D.1563 + &c, index: D.1562] = MEM[base: D.1562];
> 
> WTFFF

This is caused by my change to ivopts in
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00198.html.


-- 


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

[Bug middle-end/29256] [4.2 regression] loop performance regression

[rakdver at gcc dot gnu dot org]

-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-09-28 02:59:57 |2006-09-28 14:44:02
   date||


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

[Bug libstdc++/29217] locale confusion with time/collate categories

[paolo at gcc dot gnu dot org]

--- Comment #6 from paolo at gcc dot gnu dot org  2006-09-28 14:40 ---
Subject: Bug 29217

Author: paolo
Date: Thu Sep 28 14:40:46 2006
New Revision: 117283

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117283
Log:
2006-09-28  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/29217
* include/bits/locale_classes.h: Fix (swap) numerical encodings of
time and collate categories.
* src/locale_init.cc: Consistently reorder locale::_Impl::_S_id_time
and _S_id_collate.
* src/locale.cc: Tweak.

Modified:
branches/libstdcxx_so_7-branch/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch


-- 


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

[Bug libstdc++/29217] locale confusion with time/collate categories

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2006-09-28 14:40 ---
Subject: Bug 29217

Author: paolo
Date: Thu Sep 28 14:40:12 2006
New Revision: 117282

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117282
Log:
2006-09-28  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/29217
* include/bits/locale_classes.h: Fix (swap) numerical encodings of
time and collate categories.
* src/locale_init.cc: Consistently reorder locale::_Impl::_S_id_time
and _S_id_collate.
* src/locale.cc: Tweak.

Modified:
branches/libstdcxx_so_7-branch/libstdc++-v3/include/bits/locale_classes.h
branches/libstdcxx_so_7-branch/libstdc++-v3/src/locale.cc
branches/libstdcxx_so_7-branch/libstdc++-v3/src/locale_init.cc


-- 


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

[Bug middle-end/29256] [4.2 regression] loop performance regression

[rakdver at gcc dot gnu dot org]

--- Comment #14 from rakdver at gcc dot gnu dot org  2006-09-28 14:40 
---
> > > for this loop instead of just one.
> > > Actually unrolling is not need to produced the bad code:
> > > .L2:
> > > lwz 0,0(9)
> > > stwx 0,11,9
> > > addi 9,9,4
> > > bdnz .L2
> > > I bet a beer that loop.c actually fixed this crap up before.
> > 
> > I am bad at reading ppc assembler; could you please explain what exactly is
> > wrong with the code you present?
> 
> One, there are two adds still there (just one is implicated)
> so why not do the loop as:

there is only one add, as far as I can see.

>  .L2:
>  lwz r0,0(r9)
>  stw r0,0(r11)
>  addi r9,r9,4
>  addi r11,r11,4
>  bdnz .L2

Otoh, this seems worse to me (one more add).

> Or:
>  .L2:
>  lwxz r0,r9,r12
>  stwx r0,r11,r12
>  addi r12,r12,4
>  bdnz .L2

Yes, this would be about the same.  Still, ivopts chose one of the best
possible ways, so I do not see what you are complaining about so much.
The unrolled case is something different -- of course we should use offsetted
modes there.


-- 


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

[Bug middle-end/29256] [4.2 regression] loop performance regression

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2006-09-28 14:34 
---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > Oh, didn't I fix this?  See PR26726.
> > This is unrelated to that as the trees produced is defined but just looks 
> > weird
> > and really the one IV selection is messed up.  It should have chosen two IVs
> > for this loop instead of just one.
> > Actually unrolling is not need to produced the bad code:
> > .L2:
> > lwz 0,0(9)
> > stwx 0,11,9
> > addi 9,9,4
> > bdnz .L2
> > I bet a beer that loop.c actually fixed this crap up before.
> 
> I am bad at reading ppc assembler; could you please explain what exactly is
> wrong with the code you present?

One, there are two adds still there (just one is implicated)
so why not do the loop as:
 .L2:
 lwz r0,0(r9)
 stw r0,0(r11)
 addi r9,r9,4
 addi r11,r11,4
 bdnz .L2
Or:
 .L2:
 lwxz r0,r9,r12
 stwx r0,r11,r12
 addi r12,r12,4
 bdnz .L2


-- 


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

[Bug middle-end/29256] [4.2 regression] loop performance regression

[rakdver at gcc dot gnu dot org]

--- Comment #12 from rakdver at gcc dot gnu dot org  2006-09-28 14:21 
---
(In reply to comment #11)
> (In reply to comment #9)
> > Oh, didn't I fix this?  See PR26726.
> This is unrelated to that as the trees produced is defined but just looks 
> weird
> and really the one IV selection is messed up.  It should have chosen two IVs
> for this loop instead of just one.
> Actually unrolling is not need to produced the bad code:
> .L2:
> lwz 0,0(9)
> stwx 0,11,9
> addi 9,9,4
> bdnz .L2
> I bet a beer that loop.c actually fixed this crap up before.

I am bad at reading ppc assembler; could you please explain what exactly is
wrong with the code you present?


-- 


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

[Bug middle-end/29256] [4.2 regression] loop performance regression

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2006-09-28 14:16 
---
(In reply to comment #9)
> Oh, didn't I fix this?  See PR26726.
This is unrelated to that as the trees produced is defined but just looks weird
and really the one IV selection is messed up.  It should have chosen two IVs
for this loop instead of just one.
Actually unrolling is not need to produced the bad code:
.L2:
lwz 0,0(9)
stwx 0,11,9
addi 9,9,4
bdnz .L2
I bet a beer that loop.c actually fixed this crap up before.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2 regression] loop   |[4.2 regression] loop
   |unrolling performance   |performance regression
   |regression  |


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

[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression

[rakdver at gcc dot gnu dot org]

--- Comment #10 from rakdver at gcc dot gnu dot org  2006-09-28 14:15 
---
(In reply to comment #8)
>   D.1563 = -&a;
>   MEM[base: (int *) D.1563 + &c, index: D.1562] = MEM[base: D.1562];
> 
> WTFFF

ivopts are having fun :-)  On the other hand, this is (one of several possible)
cheapest ways how to express the code, and it should not affect creation of
offsetted modes on RTL, so although this is indeed somewhat curious (well, bug
in fact, from reasons unrelated to the problem covered by this PR), it is not
the cause of this problem.

On x86, tree optimizers seem to do just fine, producing

MEM[symbol: c, index: D.1569, step: 8B] = MEM[symbol: a, index: D.1569, step:
8B];

However, on RTL, we fail to create offsetted version of this addressing mode
after unrolling.


-- 


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

[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2006-09-28 14:11 ---
Oh, didn't I fix this?  See PR26726.


-- 


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

[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-09-28 14:08 ---
  D.1563 = -&a;
  MEM[base: (int *) D.1563 + &c, index: D.1562] = MEM[base: D.1562];

WTFFF


-- 


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

[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-09-20 07:50:15 |2006-09-28 14:08:26
   date||


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

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #27 from pault at gcc dot gnu dot org  2006-09-28 14:06 ---
Created an attachment (id=12350)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12350&action=view)
The latest version, incorporating all fixes so far.

This latest has an increasingly complete set of testcases and fixes for the
problems found by Salvatore Filippone.

What is missing is the setting of scalar assignment flags for WHERE
blocks/statements and another attempt to understand what is broken with zero
length strings (for iso_varying_string).

A ChangeLog exists, which is about two days behind.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #12320|0   |1
is obsolete||


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

[Bug libfortran/23889] behaviour of random_seed()

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2006-09-28 14:05 
---
After a year and not patch has been proposed for that enhancement, it looks
like it won't be implemented in gfortran.

Still, feel free to reopen this PR (or file a new one) if you have a patch
ready.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2006-09-28 14:02 ---
Oh, but those do not happen on x86_64.  So this is a target issue really.


-- 


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

[Bug c++/9937] [DR 176] Base class template name is not injected properly into derived class

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-09-28 14:02 ---
*** Bug 29265 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||4ekucT at tut dot by


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

[Bug c++/29265] Type resolving for template class hierarchy

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-28 14:02 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-09-28 13:47 ---
(In reply to comment #4)
> On x86_64 4.2 decides to unroll 9 times while on 4.1 it unrolls 8 times.  This
> is
> a code-size regression, but other than that?  The 4.2 version runs slightly
> faster than the 4.1 version, though the difference may be in the noise.

No, no, no, I and Edmar are not complaining about how many times it unrolled
but the use of index addressing mode instead of offset addressing mode for the
stores and the extra adds.


-- 


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

[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-28 13:39 ---
There is no
tdat_hash_map(_Alloc&) in the sources.
Adding one makes it get past that error and then we get:
t.cc: In constructor ‘tdat_hash_map<_AllocType>::tdat_hash_map(const
_AllocType&) [with _AllocType = MemAllocator]’:
t.cc:64:   instantiated from here
t.cc:38: error: ‘MemAllocator::MemAllocator() [with Type = int]’ is
private
t.cc:49: error: within this context


So this is invalid still.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug other/29260] Calling member function of const object causes segmentation fault in compiler

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-28 13:29 ---
The D front-end is not part of the FSF GCC right now, you should report this to
the place where you got the compiler.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-09-28 13:09 ---
Confirmed.

(gdb) bt
#0  fancy_abort (
file=0xc80d78 "/space/rguenther/src/svn/trunk/gcc/emit-rtl.c", line=1353, 
function=0xc80ef0 "operand_subword_force")
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:642
#1  0x0061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, 
mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353
#2  0x006351a6 in store_bit_field (str_rtx=0x2b22e2375ba0, 
bitsize=256, bitnum=0, fieldmode=QImode, value=0x2b22e2362f40)
at /space/rguenther/src/svn/trunk/gcc/expmed.c:582
#3  0x0065441b in store_field (target=0x2b22e2375ba0, bitsize=256, 
bitpos=0, mode=BLKmode, exp=0x2b22e23639a0, type=0x2b22e2359d10, 
alias_set=0) at /space/rguenther/src/svn/trunk/gcc/expr.c:5591
#4  0x0064d0e2 in expand_assignment (to=0x2b22e235a300, 
from=0x2b22e23639a0) at /space/rguenther/src/svn/trunk/gcc/expr.c:4141
#5  0x0066d9cf in expand_expr_real_1 (exp=0x2b22e235b870, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:8603
#6  0x0065a675 in expand_expr_real (exp=0x2b22e235b870, 
target=0x2b22e2284400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:6700
(gdb) up
#1  0x0061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, 
mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353
1353  gcc_assert (result);
(gdb) list
1348  else
1349op = force_reg (mode, op);
1350}
1351
1352  result = operand_subword (op, offset, 1, mode);
1353  gcc_assert (result);
1354
1355  return result;
1356}
1357^L

We're asking for a QImode subword at offset 0 of
(mem/s/j:BLK (plus:DI (reg:DI 112)
(reg:DI 96 [ D.1297 ])) [0 S32 A8])

in expansion of

(*D.1297)[S.20D.1298] = D.1302


4.0 fails differently:

gcc40-g/gcc> ./f951 -quiet ../../gcc41-g/gcc/t.f90 
../../gcc41-g/gcc/t.f90: In function 'MAIN__':
../../gcc41-g/gcc/t.f90:8: internal compiler error: in gfc_conv_function_call,
at fortran/trans-expr.c:1108
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2006-09-28 13:09:57
   date||


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

[Bug other/29260] Calling member function of const object causes segmentation fault in compiler

[leg0 at hot dot ee]

--- Comment #2 from leg0 at hot dot ee  2006-09-28 11:38 ---
The compiler that does this is not a C nor C++ compiler. It's D compiler (gdc).


-- 

leg0 at hot dot ee changed:

   What|Removed |Added

  Component|c++ |other


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

[Bug fortran/25087] Error for missing explicit interface needed.

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2006-09-28 11:35 
---
There's a TODO about this in front-end resolve.c. It's a good point to start...

static void
resolve_formal_arglist (gfc_symbol * proc)
{
  gfc_formal_arglist *f;
  gfc_symbol *sym;
  int i;

  /* TODO: Procedures whose return character length parameter is not constant
 or assumed must also have explicit interfaces.  */


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Last reconfirmed|2005-11-29 12:06:22 |2006-09-28 11:35:17
   date||


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

[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression

[rakdver at gcc dot gnu dot org]

--- Comment #5 from rakdver at gcc dot gnu dot org  2006-09-28 11:34 ---
(In reply to comment #4)
> On x86_64 4.2 decides to unroll 9 times while on 4.1 it unrolls 8 times.  This
> is
> a code-size regression, but other than that?  The 4.2 version runs slightly
> faster than the 4.1 version, though the difference may be in the noise.

Choosing 9 instead of 8 looks weird, though :-).  The reason is following:
jump threading in vrp2 pass peels one iteration of the loop.  With this change,
unrolling by factor of 9 creates smaller code (only one extra iteration needs
to be peeled to make the number of iterations divisible by 9, while one would
need to peel 7 more iterations to make it divisible by 8).


-- 


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

[Bug target/29258] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2006-09-28 11:21 ---
Works for me with 3.4.6 (x86_64) and 3.4.3 (i686).  Did not try a
cross-compiler though.


-- 


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

[Bug driver/29270] "--" does not end option parsing

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2006-09-28 11:21 ---
See also the thread at
.


-- 


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

[Bug driver/29270] New: "--" does not end option parsing

[schwab at suse dot de]

$ gcc hello.c -- -MM
hello.o: hello.c
gcc: ambiguous abbreviation --


-- 
   Summary: "--" does not end option parsing
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de


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

[Bug c++/29260] Calling member function of const object causes segmentation fault in compiler

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-09-28 11:14 ---
Works for me on i686-linux with all versions.  Also the code in question is
invalid:

t.C:9: error: '::main' must return 'int'
t.C: In function 'int main()':
t.C:11: error: uninitialized const 'y'
t.C:12: error: passing 'const Y' as 'this' argument of 'void Y::f()' discards
qualifiers


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|other   |c++
   Keywords||ice-on-invalid-code


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

[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2006-09-28 11:08 ---
On x86_64 4.2 decides to unroll 9 times while on 4.1 it unrolls 8 times.  This
is
a code-size regression, but other than that?  The 4.2 version runs slightly
faster than the 4.1 version, though the difference may be in the noise.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, rakdver at gcc dot gnu
   ||dot org


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

[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2006-09-28 10:55 ---
Confirmed.  The warning is correct - we emit it with explicit casts, too.  But
surprisingly -Wno-cast-qual does not get rid of it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||error-recovery, ice-
   ||checking, ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2006-09-28 10:55:21
   date||


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

[Bug middle-end/29269] New: missing documentation for "vcond" (vector conditional operation)

[dorit at il dot ibm dot com]

missing documentation for "vcond" (vector conditional operation).


-- 
   Summary: missing documentation for "vcond" (vector conditional
operation)
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com


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

[Bug middle-end/29268] New: missed optimization: need to generalize realignment support in the vectorizer

[dorit at il dot ibm dot com]

details in theis thread:
http://gcc.gnu.org/ml/gcc/2006-09/msg00503.html

Need to add other ways to handle realignment, that are applicable to targets
that can't support the realign_load the way it is currently defined.


-- 
   Summary: missed optimization: need to generalize realignment
support in the vectorizer
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com


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

[Bug fortran/29267] New: ICE in operand_subword_force, at emit-rtl.c:1353

[franke dot daniel at gmail dot com]

$> cat ice.f90
PROGRAM test_ice
  CHARACTER(len=255), DIMENSION(1,2)  :: a
  a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))

  CONTAINS
CHARACTER(32) FUNCTION to_string(x)
  REAL, INTENT(in) :: x
  WRITE(to_string, FMT="(F6.3)") x
END FUNCTION
END PROGRAM

$> gfortran-4.2 -g -Wall ice.f90
ice.f90: In function ‘MAIN__’:
ice.f90:3: internal compiler error: in operand_subword_force, at
emit-rtl.c:1353
Please submit a full bug report,

$> gfortran -v 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure
--prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-4.2-svn
--enable-threads=posix --enable-shared --with-system-zlib
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0 20060914 (experimental)

Initially reported here:
http://gcc.gnu.org/ml/fortran/2006-09/msg00335.html
(the testcase above is a reduced version of that posted to the ML)


-- 
   Summary: ICE in operand_subword_force, at emit-rtl.c:1353
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: franke dot daniel at gmail dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug middle-end/29253] expand_abs wrong default code for floating point

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-09-28 09:59 ---
Confirmed.  As expand_copysign, expand_fabs should defer to the library in this
case.


-- 

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 |2006-09-28 09:59:18
   date||


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

[Bug c++/29266] New: Rule that binding rvalue to a refernce need a copy ctor don't work

[yuanfei8077 at gmail dot com]

Hi,

I used to open a issue at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29261 and
it's closed as no a bug.  Also it says that to bind an rvalue to a reference,
we need to let copy ctor of the class be accessible.  However, I found that
this is not the case when the invokcation is happen in intialization list.

See below reproduction code and error message.
Env:
=
G++ 4.1
No compile option is used

Source code:
==

using std::cout;
using std::endl;


class MemPool {
public:
   MemPool(){};
protected:
   MemPool(const MemPool& mempool);

};

template  class MemAllocator{

public:
   MemAllocator(MemPool& pool):m_pool(pool){}
   MemPool& get_pool() const {
   return m_pool;
   }
   template
   MemAllocator& operator=(const MemAllocator& rhs){
   m_pool = rhs.get_pool();
   return *this;
   }
   MemAllocator& operator=(const MemAllocator& rhs){
   m_pool = rhs.get_pool();
   return *this;
   }

   MemAllocator(const MemAllocator& other)
   : m_pool(other.m_pool) {}
   template
   MemAllocator(const MemAllocator& other)
   : m_pool(other.get_pool()) {}

private:
   MemAllocator();
//  MemAllocator(const MemAllocator&);
   MemPool &m_pool;

};


template  class tdat_hash_map {
public:
   typedef _AllocType _Alloc;

   static void func(const _Alloc&) {};

   _Alloc malloc;
private:
   tdat_hash_map();
};
class CacheManager {
public:

   typedef tdat_hash_map > Map;

   Map caches;
   MemPool pool;
   CacheManager():caches(MemAllocator(pool)){};

};

Error message:
==
main.cpp: In constructor CacheManager::CacheManager()
main.cpp:56: error: no matching function for call to

tdat_hash_map

>::tdat_hash_map(MemAllocator)main.cpp:49: note: candidates are:
tdat_hash_map<_AllocType>::tdat_hash_map() [with _AllocType =
MemAllocator]
main.cpp:42: note: tdat_hash_map
>::tdat_hash_map(const tdat_hash_map >&)


-- 
   Summary: Rule that binding rvalue to a refernce need a copy ctor
don't work
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuanfei8077 at gmail dot com


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

[Bug c++/29265] Type resolving for template class hierarchy

[4ekucT at tut dot by]

--- Comment #1 from 4ekucT at tut dot by  2006-09-28 09:05 ---
Created an attachment (id=12349)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12349&action=view)
Type resolving for template class hierarchy


-- 


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

[Bug c++/29265] New: Type resolving for template class hierarchy

[4ekucT at tut dot by]

If we have two template classes in hierarchy and try to take type of the
topmost class, gcc shows error message while VC 8.0 and Comeau C/C++ 4.3.3 does
not.

The following exapmle shows code that generates the error:

template 
class A
{
public:
  typedef int TType;

private:
  typedef T tmp;
};

template 
class B : public A
{
public:
  typedef char* TType;

private:
  typedef T tmp;
};

template 
class Test
{
public:
  static void test()
  {
typename B::A::TType a = 0;
typename B::TType b = "test";
  }
};


int main(int argc, char* argv[])
{
  Test::test();
}

Error message is following:
test.cpp: In static member function `static void Test:
:test() [with T = int]':
test.cpp:35:   instantiated from here
test.cpp:27: error: no type named `A' in `class B'


-- 
   Summary: Type resolving for template class hierarchy
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 4ekucT at tut dot by


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

[Bug fortran/28655] [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-09-28 08:03:35
   date||


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-09-28 08:02 
---
Confirmed, and marked as blocking the F2003 meta-PR.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
OtherBugsDependingO||20585
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-09-28 08:02:35
   date||
Summary|Fortran 2003: Support type- |Fortran 2003: Support type-
   |spec for array constructor, |spec for array constructor
   |i.e. (/ real :: 1., 2., 3.  |
   |/)  |


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

[Bug fortran/23375] show location for runtime errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2006-09-28 07:59 
---
Closing, as the error messages have been modified to include source location.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/23060] %VAL construct not implemented

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2006-09-28 07:58 
---
Changing this into a bug, since it was implemented in g77. It might be working
soon, since we will soon have ISO_C_BINDING val attribute, which does the same
thing, so adding the %val construct will probably be very easy.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Severity|enhancement |normal
 GCC target triplet|i386-redhat-linux   |
   Last reconfirmed|2006-03-05 03:41:17 |2006-09-28 07:58:23
   date||


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