[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-20 08:21 
---
Subject: Bug 17832

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-20 08:21:10

Modified files:
fixincludes: ChangeLog fixincl.c fixlib.h procopen.c 

Log message:
PR bootstrap/17832

* fixincl.c (SIGCHLD): Remove definition.
(initialize): Remove SIGIOT and SIGPIPE checks.
(create_file): Fix mkdir() for Win32.
(internal_fix): Use dup2() instead of fcntl().

* fixlib.h (SIGQUIT): Define if undefined.
(SIGIOT): Same.
(SIGPIPE): Same.
(SIGALRM): Same.
(SIGKILL): Same.

* procopen.c (chain_open): Use dup2() instead of fcntl().

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&r1=1.9&r2=1.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixlib.h.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/procopen.c.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2004-10-20 08:39 
---
One more patch left to be reviewed, besides PR17991:
.


-- 


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

[Bug c++/18072] New: Function overload being selected from file scope instead of template class scope when called from base template class

[dwoldrich_ebay at yahoo dot com]

This problem evolved out of my trying to implement a context aware logger.  It
appears that template classes with template parameters that themselves have
template parameters can cause gcc to be unable to select an overload from the
class correctly and incorrectly goes to the file scope for the default method. 
It's very confusing and hard to explain...  I will paste the code below, but
hopefully there is a attach function I can use later on to just attach the
source file.  

In VC6.0, the code prints the following when run:

  I'd really love to call my base class'es method ... and the base class is
indeed printing as I had hoped it would.

In GCC 3.4.1, the code prints the following (undesired/incorrect?) when run:

  I'd really love to call my base class'es method... but the file scoped
function is selected!  WAH!  Why does GCC and/or the C++ standard hate me so!?


I believe there is something specific about the following line that the compiler
is not processing correctly:

  template class DERIVED : public BASETEMPLATE< DERIVED >


using GCC from mingw:

Reading specs from ../lib/gcc/mingw32/3.4.1/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.1 (mingw special)


compiled with:

gcc -c -g -mwindows -DWIN32 -D_WINDOWS -D_DEBUG -IC:\devproject\woldie\protos
-std=gnu++98 -felide-constructors -frepo -fshort-enums -fshort-wchar
-fkeep-static-consts -ftemplate-depth-255 -mms-bitfields -march=i586
-malign-stringops -mfancy-math-387 -mhard-float -mfp-ret-in-387 -m32
-mno-mmx-mno-3dnow -mno-sse -mno-sse2 -mno-sse3
C:\devproject\woldie\protos\testforfails.cpp


linked with:

gcc -g -Wl,--force-exe-suffix -o protos protos\Debug\testforfails.o
-LC:\MinGW\lib\debug -Wl,-Bstatic -lstdc++ -Wl,-Bstatic -lsupc++ -lkernel32
-luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32
-luuid -lodbc32 -lodbccp32



here's the code:

#include 

class BASEOFBASE
{
  public:
BASEOFBASE(void) {}
virtual ~BASEOFBASE(void) {}
};

extern BASEOFBASE& PrintSumpthin(void);

template class BASETEMPLATE : public BASEOFBASE
{
  private:
mutable int whocaresjustignoreme;

  protected:
BASETEMPLATE(void) {}
friend BASEOFBASE& ::PrintSumpthin(void);

  public:
virtual const BASEOFBASE& PrintSumpthin(void) const
{
  printf(" ... and the base class is indeed printing as I had hoped it
would.\n");

  return(*this);
}

virtual BASEOFBASE& PrintSumpthin(void)
{
  printf(" ... and the base class is indeed printing as I had hoped it
would.\n");

  return(*this);
}

  public:
virtual ~BASETEMPLATE(void) {}
};

template class DERIVED : public BASETEMPLATE< DERIVED >
{
  private:
ANYTYPE2 thistoodoesnotmatterawhit;

  public:
DERIVED(void) {}
~DERIVED(void) {}

void ImGonnaPrint(void)
{
  printf("I'd really love to call my base class'es method");
  PrintSumpthin();
}
};

int main(int argc, char** argv)
{
  DERIVED* myDerived = new DERIVED();

  myDerived->ImGonnaPrint();

  return(0);
}

BASEOFBASE& PrintSumpthin(void)
{
  static BASETEMPLATE thisisjustheretoconfuse;

  printf("... but the file scoped function is selected!  WAH!  Why does GCC
and/or the C++ standard hate me so!?\n");

  return(thisisjustheretoconfuse);
}

-- 
   Summary: Function overload being selected from file scope instead
of template class scope when called from base template
class
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwoldrich_ebay at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18072] Function overload being selected from file scope instead of template class scope when called from base template class

[dwoldrich_ebay at yahoo dot com]

--- Additional Comments From dwoldrich_ebay at yahoo dot com  2004-10-20 09:29 
---
Created an attachment (id=7384)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7384&action=view)
Source code

This is the source code to the test I wrote.

-- 


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

gcc-bugs@gcc.gnu.org

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-20 09:33 
---
Do we want to add a testcase to testsuite for this?


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/11240] Pointer comparison problem when using constructors

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-20 09:49 
---
Fixed by Mark's patch
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01166.html

Do we want to have a testcase for this one?


-- 
   What|Removed |Added

 CC||mark at codesourcery dot com
 Status|NEW |RESOLVED
  Known to fail|2.95.3 3.2.3 3.3.3 3.4.0 4.0|2.95.3 3.2.3 3.3.3 3.4.0
  Known to work||4.0.0
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug c++/10841] rejects valid explicit type conversion to/from pointers-to-member of private base

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-20 09:54 
---
With Mark's patch
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01166.html
we now get an additional ICE on mainline:

bug.cc: In function `int main()':
bug.cc:6: error: 'main()::Base' is an inaccessible base of 'main()::Derived'
bug.cc:9: error: 'main()::Base' is an inaccessible base of 'main()::Derived'
bug.cc:9: internal compiler error: tree check: expected tree_binfo, have
error_mark in binfo_from_vbase, at cp/search.c:2425
Please submit a full bug report, [etc.]


-- 
   What|Removed |Added

 CC||mark at codesourcery dot com
   Keywords||error-recovery, ice-on-
   ||valid-code


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

[Bug c++/18073] New: [4.0 regression] mmintrin.h rejected by C++ frontend

[reichelt at gcc dot gnu dot org]

Mark, since your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01166.html
the C++ frontend rejects the following code:

=
#include
=

I get gazillions of messages like
/Work/reichelt/GCC/FARM/gcc-4.0-20041020/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/include/mmintrin.h:
In function `int __vector__ _mm_cvtsi32_si64(int)':
/Work/reichelt/GCC/FARM/gcc-4.0-20041020/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/include/mmintrin.h:62:
error: invalid cast from type 'long long int' to type 'int __vector__'

-- 
   Summary: [4.0 regression] mmintrin.h rejected by C++ frontend
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com


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

[Bug inline-asm/18074] New: SSE2 intrinsics generates wrong code

[jochang at gmail dot com]

The command line: gcc -O2 -msse2 -S 2.c
The code:
#include 
int f(__m128i x, __m128i y)
{
  __m128i m[1];
  m[0] = _mm_add_epi16(x, y);
  return *(int*)(&m[0]);
}
int g(__m128i x, __m128i y)
{
  __m128i m[2];
  m[0] = _mm_add_epi16(x, y);
  return *(int*)(&m[0]);
}

The compiler generates correct code for f(),
but for g() the add operation (paddw) disappears.
Happens on GCC 3.3.4 and 3.4.2

-- 
   Summary: SSE2 intrinsics generates wrong code
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jochang at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
 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=18074

[Bug c++/18075] New: #pragma implementation broken in presence of #pragma ident

[ebotcazou at gcc dot gnu dot org]

I get with the testcase I'm about to attach:

[EMAIL PROTECTED] gcc-4.0 -S -Wall pragma_bug.ii
/home/eric/cvs/gcc/libjava/java/lang/natClass.cc:34: warning: ignoring #pragma
ident implementation

With 3.4.3pre, all works fine.  This is critical on Solaris because there are
#pragma ident all over the place in the header files.  This also prevents libgcj
from building on Solaris.

-- 
   Summary: #pragma implementation broken in presence of #pragma
ident
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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

[Bug c++/18075] #pragma implementation broken in presence of #pragma ident

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-20 11:43 
---
Created an attachment (id=7385)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7385&action=view)
Testcase extracted from libgcj.


-- 


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

[Bug target/18074] SSE2 intrinsics generates wrong code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|inline-asm  |target
   Keywords||wrong-code


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build, wrong-code
Summary|#pragma implementation  |[4.0 Regression] #pragma
   |broken in presence of   |implementation broken in
   |#pragma ident   |presence of #pragma ident
   Target Milestone|--- |4.0.0


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

[Bug target/18074] SSE2 intrinsics generates wrong code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 11:59 
---
Either use an union to extract the component or use -fno-strict-aliasing.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug java/17265] [4.0 Regression] Libjava doesn't build

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-20 11:59 
---
> That sounds like C++ bug.

Indeed, relating to the handling of #pragma (PR c++/18075).


-- 
   What|Removed |Added

  BugsThisDependsOn||18075


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

[ebotcazou at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||17265
  nThis||


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

[Bug target/18074] SSE2 intrinsics generates wrong code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 11:59 
---
Either use an union to extract the component or use -fno-strict-aliasing.

You are violating aliasing rules.

-- 


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

[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 12:00 
---
Confirmed.  This should be accepted.

-- 
   What|Removed |Added

   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 12:00:47
   date||
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/18076] New: Missed jump threading optimization

[steven at gcc dot gnu dot org]

On AMD64 the following piece of code still triggers one jump 
threading opportunity in the RTL threader that we miss it in 
the tree threader on the tree-cleanup-branch: 
 
= 
extern int x; 
extern int y; 
 
void 
foo (void) 
{ 
  if ((x & 0x0001) || (x & 0x4000)) 
y = 0; 
  if ((x & 0x0001) || (x & 0x4000)) 
y = 1; 
  if ((x & 0x0001) || (x & 0x4000)) 
y = 2; 
  if ((x & 0x0001) || (x & 0x4000)) 
y = 3; 
  if ((x & 0x0001) || (x & 0x4000)) 
y = 4; 
} 
= 
 
This test case was reduced from insn-opinit.c where we're still 
threading 405 jumps, most of them of the kind shown in the test 
case, with the RTL threader. 
 
We do catch this on mainline. 
 
The assembly for the tree-cleanup-branch is worse than mainline: 
 
MAINLINE: -O2   TCB: -O2 
.file   "t.c"   .file   "t.c" 
.text   .text 
.p2align 4,,15  .p2align 4,,15 
.globl foo  .globl foo 
.type   foo, @function  .type   foo, @function 
foo:foo: 
.LFB2:  .LFB2: 
movlx(%rip), %eax   movlx(%rip), %eax 
movl%eax, %edx  movl%eax, %edx 
andl$1, %edxandl$1, %edx 
jne .L2 jne .L2 
testb   $64, %ahtestb   $64, %ah 
je  .L19  | je  .L4 
.L2:.L2: 
testb   %dl, %dltestb   %dl, %dl 
movl$0, y(%rip) movl$0, y(%rip) 
je  .L23  | jne .L5 
  > testb   $64, %ah 
  > je  .L4 
  > .L5: 
testb   %dl, %dltestb   %dl, %dl 
movl$1, y(%rip) movl$1, y(%rip) 
je  .L24  | je  .L4 
.L10: < 
testb   %dl, %dltestb   %dl, %dl 
movl$2, y(%rip) movl$2, y(%rip) 
je  .L25  | je  .L16 
.L14: | .L9: 
testb   %dl, %dltestb   %dl, %dl 
movl$3, y(%rip) movl$3, y(%rip) 
je  .L26  | je  .L17 
.L17: | .L12: 
movl$4, y(%rip) movl$4, y(%rip) 
.L19: | .L14: 
rep ; ret   rep ; ret 
.p2align 4,,7   .p2align 4,,7 
.L23: | .L4: 
testb   $64, %ahtestb   $64, %ah 
je  .L19  | je  .L14 
testb   %dl, %dl  < 
movl$1, y(%rip)   < 
jne .L10  < 
.L24: < 
testb   $64, %ah  < 
je  .L19  < 
testb   %dl, %dltestb   %dl, %dl 
movl$2, y(%rip) movl$2, y(%rip) 
jne .L14  | jne .L9 
.L25: | jmp .L16 
  > .p2align 4,,7 
  > .L17: 
testb   $64, %ahtestb   $64, %ah 
je  .L19  | .p2align 4,,2 
  > je  .L14 
  > movl$4, y(%rip) 
  > .p2align 4,,4 
  > jmp .L14 
  > .p2align 4,,7 
  > .L16: 
  > testb   $64, %ah 
  > .p2align 4,,2 
  > je  .L14 
testb   %dl, %dltestb   %dl, %dl 
movl$3, y(%rip) movl$3, y(%rip) 
jne .L17  | jne .L12 
.L26: < 
testb   $64, %ah  < 
jne .L17  < 
.p2align 4,,2   .p2align 4,,2 
ret  

[Bug c++/18077] New: Members of anonymous namespaces get name mangled with first global variable instead of file name

[fafa at freesurf dot ch]

Members of anonymous namespaces should get a name that is mangled in a way so 
as to make them unique. This is not the case if a global variable is defined 
before the keyword "namespace" is used. In that case the first global variable 
name is used for the name mangling. If I then link with "-z muldefs" I get 
wrong symbol resolution.

Example:
foo1.cpp:
  #include 

  int iii;
  namespace {
void f() { printf("foo1\n"); }
  }

  void foo1() { f(); }

foo2.cpp:
  #include 

  int iii;
  namespace {
void f() { printf("foo2\n"); }
  }

  void foo2() { f(); }

main.cpp:
  extern void foo1();
  extern void foo2();

  int main() {
foo1();
foo2();
return 0;
  }

g++ -o foo foo1.cpp foo2.cpp main.cpp -z muldefs

./foo
generates the output
  foo1
  foo1
instead of
  foo1
  foo2
because both mangled names for the functions f are "_ZN14_GLOBAL__N_iii1fEv", 
and the linker chosses one of the two for both calls.

The error vanishes if I just write
  namespace {}
before the definition of iii, because then the mangled name of f changes 
to "_ZN25_GLOBAL__N_foo1.cppgmEtmb1fEv" which seems the correct name to me.

-- 
   Summary: Members of anonymous namespaces get name mangled with
first global variable instead of file name
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fafa at freesurf dot ch
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 12:56 
---
: Search converges between 2004-09-20-161001-trunk (#551) and 2004-09-21-094824-trunk 
(#552).
Almost certain caused by:
2004-09-20  Matt Austern <[EMAIL PROTECTED]>
Zack Weinberg  <[EMAIL PROTECTED]>

* decl.c (make_rtl_for_nonlocal_decl, start_preparsed_function):
Apply lbasename to input_filename before passing to get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (handle_pragma_interface): Apply get_fileinfo to the
correct filename.  Rename variables to be less confusing.
(handle_pragma_implementation): Likewise.  Disable "appears
after file is included" diagnostic.

* parser.c (struct cp_token): Add in_system_header fiag.
(CP_TOKEN_BLOCK_NUM_TOKENS, struct cp_token_block)

-- 
   What|Removed |Added

 CC||zack at codesourcery dot
   ||com, austern at apple dot
   ||com
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 12:56:10
   date||


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

[Bug c++/18077] [3.3/3.4/4.0 Regression] Members of anonymous namespaces get name mangled with first global variable instead of file name

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 13:05 
---
Confirmed, a regression from 3.0.4.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
  Known to fail||3.3.3 3.4.0 4.0.0
  Known to work||3.0.4
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 13:05:57
   date||
Summary|Members of anonymous|[3.3/3.4/4.0 Regression]
   |namespaces get name mangled |Members of anonymous
   |with first global variable  |namespaces get name mangled
   |instead of file name|with first global variable
   ||instead of file name
   Target Milestone|--- |3.4.3


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

[Bug c++/18072] Function overload being selected from file scope instead of template class scope when called from base template class

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 13:11 
---
Did you read the release notes?  This is documented in them and how the code should 
change.

Invalid by the C++ standard.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

gfortran internal compiler error - "Please submit a full bug report" being attempted

[Gordon Sande]

Reporting the bug requires setting up my 1,070,045th user account  
somewhere
so I will use the email version as the gccbug script exists somewhere  
else.

Mac Os X 10.3.5
Dual 1.8 G5 Mac standard configuration, i.e middle model before first  
speed bump

"sudo fink install gfortran" used to install
after fixing the fink configuration files to find gfortran under  
"unstable"
and fighting with the stupid installation which did not like the Aqua  
X11
which had never before required the SDK. Somebody's attempt at being  
helpful
was a major PITA. Why would a command line compiler need X11? Either  
they
think everyone else will want it, which is not he case. Or they require  
some
piece of it as a utility, which is curious software engineering. Yes,  
fink
isn't gfortran but it is rather hard to tell them apart while the  
install
is in progress.

g5Mac:~/Cmd/gfortran gordon$ gfortran -v
Reading specs from /sw/lib/gcc/powerpc-apple-darwin7.5.0/3.5.0/specs
Configured with: ../gcc-3.5-20040815/configure --prefix=/sw  
--enable-languages=f95 --infodir=/share/info --with-gmp=/sw  
--disable-shared
Thread model: posix
gcc version 3.5.0 20040815 (experimental)

g5Mac:~/Cmd/gfortran gordon$ gfortran gfortran_bug.f90
gfortran_bug.f90: In function `initch':
gfortran_bug.f90:0: internal compiler error: in check_pointer_types_r,  
at gimplify.c:4261
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

 
=
module typasc
 implicit none
 integer(kind=1)::asctab(256)
end module typasc
module typchr
 implicit none
 character(len=1)::chrtab(256)
end module typchr
module programs
 implicit none
 contains
  subroutine main
   implicit none
   call initch
   stop
  end subroutine main
  subroutine initch
   use typchr
   use typasc
   implicit none
   integer::i,ia,ic
   character(len=1)::txblnk=" "
   integer::asblnk=32
   character(len=1)::text(95)=(/"  
","!",'"',"#","$","%","&","'","(",")","*","+",",","-",".","/","0","1","2 
","3","4","5", &
  
"6","7","8","9",":",";","<","=",">","?","@","A","B","C","D","E","F","G", 
"H","I","J","K","L","M","N","O","P","Q","R" &
  
,"S","T","U","V","W","X","Y","Z","[","\","]","^","_","`","a","b","c","d" 
,"e","f","g","h","i","j","k","l","m","n", &
 "o","p","q","r","s","t","u","v","w","x","y","z","{","|","}","~"/)

integer(kind=1)::ascii(95)=(/ 
32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55, 
56,57,58,59,60, &
  
61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84, 
85,86,87,88,89,90,91,92,93,94,95,96,97,98, &
  
99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,1 
17,118,119,120,121,122,123,124,125,126/)
   do i=1,256
 asctab(i)=asblnk
 chrtab(i)=txblnk
   end do
   do i=1,95
 ic=ascii(i)
 chrtab(ic+1)=text(i)
 ia=ichar(text(i))
 asctab(ia+1)=ascii(i)
   end do
   return
  end subroutine initch
end module programs
program acssuprs
 use programs
 implicit none
 call main
end program acssuprs
 
=

Gordon Sande  Sande & Associates
(902) 443-252810 Regency Park Drive #604
[EMAIL PROTECTED]  Halifax, Nova Scotia B3S 1P2

[Bug c++/18055] seems not possible to specialize a template member function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 13:28 
---
Two things for specialization you have to define the template functions like:
template<> IOCM::Status IOCM_SequenceTempl::_unpack(IOCM::MessageBox& 
msgBox)

instead of the current without "template<>", This is rejected in 3.4.0 and above 
because of that.

The other thing instead of copy and pasting the preprocessed source, next time please 
attach it.

-- 


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

[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-20 13:38 
---
Many C++ headers also fail when compiled with -pedantic:

==
#include
==

/Work/reichelt/GCC/FARM/gcc-4.0-20041020/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu/bits/gthr-default.h:
In function `int __gthread_active_p()':
/Work/reichelt/GCC/FARM/gcc-4.0-20041020/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu/bits/gthr-default.h:108:
error: ISO C++ forbids casting between pointer-to-function and pointer-to-object


-- 


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

[Bug ada/18066] GCC error: in expand_call, at calls.c

--- Additional Comments From "RUNKLE, TIMOTHY A dot  (TIM) (JSC-EG) (NASA)"
   2004-10-20 13:40 ---
Subject: RE:  GCC error: in expand_call, at calls.c

Hello,
Thanks for looking at the bug. It does indeed look like the bug you
mentioned below. What is the fix? I extracted code from the GtkAda cvs
database yesterday and got this error.

Thanks for your help.
Tim.

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 19, 2004 4:42 PM
To: RUNKLE, TIMOTHY A. (TIM) (JSC-EG) (NASA)
Subject: [Bug ada/18066] GCC error: in expand_call, at calls.c



--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19
21:41 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 


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

[Bug ada/18066] GCC error: in expand_call, at calls.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 13:46 
---
Use 3.4.0 and above.

-- 


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

[Bug c/18070] Contradicting function attributes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 13:49 
---
This is actually two different bugs, one target issue and one really midde-end issue 
(noinline vs 
always_inline).  I will file them sperately.

-- 
   What|Removed |Added

   Keywords||accepts-invalid


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

Re: gfortran internal compiler error - "Please submit a full bug report" being attempted

[Andrew Pinski]

On Oct 20, 2004, at 9:21 AM, Gordon Sande wrote:
Reporting the bug requires setting up my 1,070,045th user account 
somewhere
so I will use the email version as the gccbug script exists somewhere 
else.

Mac Os X 10.3.5
Dual 1.8 G5 Mac standard configuration, i.e middle model before first 
speed bump

"sudo fink install gfortran" used to install
Actually installing gfortran from source is not that hard on 
powerpc-darwin
(I do it all the time).

g5Mac:~/Cmd/gfortran gordon$ gfortran -v
Reading specs from /sw/lib/gcc/powerpc-apple-darwin7.5.0/3.5.0/specs
Configured with: ../gcc-3.5-20040815/configure --prefix=/sw 
--enable-languages=f95 --infodir=/share/info --with-gmp=/sw 
--disable-shared
Thread model: posix
gcc version 3.5.0 20040815 (experimental)
This is already fixed in a later version of gfortran, 4.0.0 20041017.
Please ask fink to update their gfortran.
Thanks,
Andrew Pinski

[Bug c++/18069] Contradicting type and variable attributes (possible regression)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 13:53 
---
Confirmed not a regression.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 13:53:04
   date||


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

[Bug target/18078] New: Contradicting function attributes (cdecl vs stdcall)

[pinskia at gcc dot gnu dot org]

/* contradicting - should be an error */
static
__attribute__((cdecl))
__attribute__((stdcall))
int test_cdecl_03(int r) { return r << 3; }


/* contradicting - should be an error */
static
__attribute__((stdcall))
__attribute__((cdecl))
int test_cdecl_04(int r) { return r << 4; }

-- 
   Summary: Contradicting function attributes (cdecl vs stdcall)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/18079] New: Contradicting function attributes (always_inline vs noinline)

[pinskia at gcc dot gnu dot org]

/* contradicting - should be an error */
static
__attribute__((noinline))
__attribute__((always_inline))
int test_inline_03(int r) { return r & 4; }

/* contradicting - should be an error */
static
__attribute__((always_inline))
__attribute__((noinline))
int test_inline_04(int r) { return r & 8; }

-- 
   Summary: Contradicting function attributes (always_inline vs
noinline)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/18070] Contradicting function attributes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 13:55 
---
I filed 18079 and 18078 for both the problems, closing as invalid.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/18032] [4.0.0] SH: wrong code for EH

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-20 13:57 
---
Subject: Bug 18032

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-20 13:57:23

Modified files:
gcc: ChangeLog 
gcc/config/sh  : sh.c 

Log message:
PR target/18032
* config/sh/sh.c (sh_expand_epilogue): Emit a blockage insn before
the frame pointer adjustment when exception handling is enabled.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5957&r2=2.5958
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sh/sh.c.diff?cvsroot=gcc&r1=1.306&r2=1.307



-- 


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

[Bug c++/18071] [3.4/4.0 Regression] -Winline does not respect -fno-default-inline

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 14:00 
---
Confirmed, a 3.4 and 4.0 regression.

But note -O3 enables -finline-functions which enables inlining for all functions so 
that is not a 
documentation problem at all.

: Search converges between 2004-01-01-trunk (#437) and 2004-01-17-trunk (#438).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 14:00:23
   date||
Summary|-Winline does not respect - |[3.4/4.0 Regression] -
   |fno-default-inline  |Winline does not respect -
   ||fno-default-inline
   Target Milestone|--- |3.4.3


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

[Bug c/18079] Contradicting function attributes (always_inline vs noinline)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 14:12 
---
Confirmed, this was break up of bug 18070.

-- 
   What|Removed |Added

 CC||markus at oberhumer dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 14:12:50
   date||


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

[Bug target/18078] Contradicting function attributes (cdecl vs stdcall)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 14:13 
---
Confirmed, this was break up of bug 18070.

-- 
   What|Removed |Added

 CC||markus at oberhumer dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 14:13:04
   date||


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

[Bug c/18063] Gcc doesn't check overflowed size of structure

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 14:13 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 14:13:37
   date||


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

[Bug libstdc++/17755] Can't compile djgpp cross-compiler

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal


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

[Bug tree-optimization/18076] Missed jump threading optimization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 14:35 
---
If I make the x variable a paramater and y a variable (return y so that y is still 
used) then it works on the 
tree level so this is an aliasing causing missed optimization.
Aka this works:
int
foo (int x)
{
 int y =-1;
 if ((x & 0x0001) || (x & 0x4000))
y = 0;
  if ((x & 0x0001) || (x & 0x4000))
y = 1;
  if ((x & 0x0001) || (x & 0x4000))
y = 2;
  if ((x & 0x0001) || (x & 0x4000))
y = 3;
  if ((x & 0x0001) || (x & 0x4000))
y = 4;
  return y;
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||alias
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 14:35:09
   date||


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

[Bug c++/18080] New: STL deque push_front, pop_front, push_back, and pop_back not O(1)

[ron at vaniwaarden dot org]

I had to implement a new deque myself (had to have special behaviour for
modifications) and could not come up with a way to do the summarized operations
in O(1).  I then looked at the deque in g++ and saw it had, basically, the same
algorithm I had come up with.

I don't know if there is an implementation of the deque that actually meets all
the performance requirements but included a program that illustrates the O(n)
growth of the summarized methods.  I admit that this is not a standard use of
the deque but still, thought it was worth mentioning and putting in the database...

#include 
#include 
#include 

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

double testDeque(int sz, int iterations)
{
  deque d;
  for (int i=0; i < sz; ++i) d.push_front(i);
  clock_t t1 = clock();
  for (int i=0; i < iterations; ++i)
  {
for (int j=0; j < sz; ++j)
{
  int f = d.front();
  d.pop_front();
  d.push_back(f);
}
  }
  clock_t t2 = clock();
  return ((double)(t2 - t1))/(double)CLOCKS_PER_SEC;
}

int main()
{
  const int sz = 1000;
  int nIts = 1;
  double eTime = testDeque(sz, nIts);
  nIts = (int)(0.01*nIts/eTime); //should make nIts calls ~10ms

  for (int testSize = sz; testSize < sz*100; testSize += 100)
  {
cout<<"Size:"

[Bug rtl-optimization/18081] New: Infinite memory allocation on -O3

[trauscher at loytec dot com]

When compiling the following code, cc1
enters an infinite loop allocating memory until
virtual memory is exhausted.

arm-rtems-elf-gcc-3.4.2 -O3 -c -otest.o test.c

The bug disappears when using -O2 or when
using -O3 with -fno-inline-functions or
-fno-gcse
It also disappears by removing lines from the
program.

test.c:

int rd(int *p) {
  if (p<((int*)4)) return 0;
  return *p;
}

void wr(int *p) {
  if (p<((int*)4)) return;
  *p = 0;
}

void test(void *p)
{
  int i;
  int a[2];

  for(i=0;i<2;i++)
  {
wr(p);
a[i]=rd(p);
  }
}

-- 
   Summary: Infinite memory allocation on -O3
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trauscher at loytec dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i386-linux
GCC target triplet: arm-rtems-elf


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

[Bug fortran/18082] New: Excessively long compile time

[schnetter at aei dot mpg dot de]

I use gcc version 
 
GNU Fortran 95 (GCC 4.0.0 20041019 (experimental)) 
 
to compile the enclosed source file with the options 
 
/home/eschnett/gcc/bin/gfortran -ftrapv -march=pentium4 -malign-double -g3 -c 
-o 
/home/eschnett/Calpha/Cactus/configs/einstein-gcc-debug/build/EHFinder/EHFinder_ReadData.F90.o
 
/home/eschnett/Calpha/Cactus/configs/einstein-gcc-debug/build/EHFinder/EHFinder_ReadData.f90
 
 
and I find that gfortran seems to enter an infinite loop.  Memory usage is 
reasonable, but after more than 17 minutes on a Pentium M 1200 MHz gfortran 
was not yet finished.  Note that there is no optimisation, and that the source 
code is straightforward, except for lengthy argument lists.

-- 
   Summary: Excessively long compile time
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org
 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=18082

[Bug libstdc++/18080] STL deque push_front, pop_front, push_back, and pop_back not O(1)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug java/18083] New: Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().

[mnefedov at rogers dot com]

Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after 
calling add().

Here is an example code to test it:

import java.util.Calendar;

public class CalendarTest {
public static void main( String [] args ) {
boolean fail = false;
Calendar c = Calendar.getInstance();

c.set( 2004, 0, 1 );
fail |= print( c, 1, 5 );

c.add( Calendar.MONTH, 1 );
fail |= print( c, 32, 1 );

c.add( Calendar.MONTH, 1 );
fail |= print( c, 61, 2 );

c.add( Calendar.MONTH, 1 );
fail |= print( c, 92, 5 );

System.exit( fail ? 1 : 0 );

}
static boolean print( Calendar c, int doy, int dow ) {
int y = c.get( Calendar.YEAR ), 
m = c.get( Calendar.MONTH ), 
d = c.get( Calendar.DAY_OF_MONTH ), 
actdoy = c.get( Calendar.DAY_OF_YEAR ), 
actdow = c.get( Calendar.DAY_OF_WEEK );

if( actdoy != doy || actdow != dow ) {
System.out.println( "FAIL: y="+y+", m="+m+", d="+d+", 
doy="+doy+", actdoy="+actdoy+", dow="+dow+", actdow="+actdow );
return true;
} else {
System.out.println( "PASS: y="+y+", m="+m+", d="+d+", 
doy="+doy+", dow="+dow);
return false;
}
}
}

-- 
   Summary: Calendar returns incorrect values for DAY_OF_YEAR and
DAY_OF_WEEK after calling add().
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mnefedov at rogers dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug fortran/18082] Excessively long compile time

[schnetter at aei dot mpg dot de]

--- Additional Comments From schnetter at aei dot mpg dot de  2004-10-20 15:53 
---
Created an attachment (id=7386)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7386&action=view)
failing source code


-- 


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

[Bug libstdc++/18080] STL deque push_front, pop_front, push_back, and pop_back not O(1)

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-20 15:57 ---
Could you please have a look to libstdc++/13537? IMO, wither we should reopen
that one or close both ;) Thanks.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug java/12760] Binary Compatibility: moving a method into a superinterface

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2004-10-20 15:58 ---
Job done.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug java/12725] [meta-bug] gcj does not conform to Binary Compatibility specification

[aph at gcc dot gnu dot org]

-- 
Bug 12725 depends on bug 12760, which changed state.

Bug 12760 Summary: Binary Compatibility: moving a method into a superinterface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12760

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libgcj/13606] need extra runtime verification of compiled code

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2004-10-20 15:59 ---
Job done.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libgcj/13603] [meta-bug] Java security model tracking PR

[aph at gcc dot gnu dot org]

-- 
Bug 13603 depends on bug 13606, which changed state.

Bug 13606 Summary: need extra runtime verification of compiled code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13606

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug java/12725] [meta-bug] gcj does not conform to Binary Compatibility specification

[aph at gcc dot gnu dot org]

-- 
Bug 12725 depends on bug 13606, which changed state.

Bug 13606 Summary: need extra runtime verification of compiled code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13606

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug java/12759] Binary compatibility: rip out -fno-assume-compiled

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2004-10-20 16:02 ---
This is fairly low priority because it doesn't really affect anything.

However, removing no-assume-compiled could cause considerable lossage.

For the time being, we could simply remove the command line option.


-- 
   What|Removed |Added

   Severity|normal  |minor
   Last reconfirmed|2004-08-09 02:01:07 |2004-10-20 16:02:51
   date||


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

[Bug java/12757] Binary Compatibility: overlap between constant pool and tables

[aph at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |minor


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

[Bug fortran/18082] Excessively long compile time

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-20 16:04 
---
Confirmed. Reduced testcase:

=
subroutine FOO ( X )
  character(len=*), intent(IN) :: X
  character(len=len(X)) :: C1, C2
  C1 = ''
  C2 = ''
end subroutine
=


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||compile-time-hog, monitored
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 16:04:26
   date||


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

[Bug libgcj/13604] AccessController unfinished

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2004-10-20 16:16 ---
Is there any special reason why this patch is unreviewed?  Might it make things
worse?


-- 


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

[Bug c++/13495] Friendship to class nested within a template is broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-20 16:20 
---
Subject: Bug 13495

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-20 16:20:51

Modified files:
gcc/cp : ChangeLog cp-tree.h decl.c friend.c parser.c 
 pt.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/g++.old-deja/g++.pt: friend44.C 
Added files:
gcc/testsuite/g++.dg/template: memfriend9.C memfriend10.C 
   memfriend11.C memfriend12.C 
   memfriend13.C memfriend14.C 
   memfriend15.C memfriend16.C 
   memfriend17.C 

Log message:
PR c++/13495
* decl.c (make_unbound_class_template): Add PARM_LIST parameter.
* cp-tree.h (make_unbound_class_template): Adjust prototype.
* parser.c (cp_parser_lookup_name): Adjust call to
make_unbound_class_template.
(cp_parser_single_declaration): Handle member class of class
template as template friend parsing correctly.
* friend.c (is_friend): Call is_specialization_of_friend for
template friend class.
(make_friend_class): Handle member class of class template as
template friend.
* pt.c (is_specialization_of_friend): Likewise.
(instantiate_class_template): Likewise.
(tsubst): Adjust call to make_unbound_class_template.

* g++.dg/template/memfriend9.C: New test.
* g++.dg/template/memfriend10.C: Likewise.
* g++.dg/template/memfriend11.C: Likewise.
* g++.dg/template/memfriend12.C: Likewise.
* g++.dg/template/memfriend13.C: Likewise.
* g++.dg/template/memfriend14.C: Likewise.
* g++.dg/template/memfriend15.C: Likewise.
* g++.dg/template/memfriend16.C: Likewise.
* g++.dg/template/memfriend17.C: Likewise.
* g++.old-deja/g++.pt/friend44.C: Remove bogus error.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4447&r2=1.4448
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1065&r2=1.1066
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1316&r2=1.1317
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/friend.c.diff?cvsroot=gcc&r1=1.101&r2=1.102
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.267&r2=1.268
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.936&r2=1.937
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4478&r2=1.4479
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend10.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend11.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend12.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend13.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend14.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend15.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend16.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/memfriend17.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.pt/friend44.C.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug c++/13495] Friendship to class nested within a template is broken

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-10-20 16:25 
---
I am closing this as fixed by patch:
  http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01709.html

For access checking problem mentioned in the comments, it's 
already covered in PR16617.  That part requires some structural 
changes that won't be investigated for some time.

-- 
   What|Removed |Added

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


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

[Bug c++/18084] New: setfill coupled with inline function: incorrect results on Linux x86

[knutejunk at austin dot rr dot com]

The problem...

The following program produces incorrect results on a Linux x86 system when 
compiled with gcc v3.4.2 (and 3.4.1) with full optimizations.  The program is 
supposed to print 0x, but instead produces random results (seems to be a 
stack corruption problem).

The source...

#include 
#include 
#include 


#define BUG

using namespace std;

class A
{
public:
   
   A () :
  valid_mask_(0xull),
  size_(0xull)
   {}
  
   uint64_t calc(uint64_t value) const {
#ifdef BUG
  return valid_mask_ & (value | size_);
#else
  // This code will never expose the bug
  uint64_t tmp = valid_mask_ & (value | size_);
  return tmp;
#endif
   }

private:
   uint64_t valid_mask_;
   uint64_t size_;
   
};

uint32_t CheckStuff()
{
   A a;
   uint64_t value = a.calc(0);
#ifdef BUG
   // This code will expose the bug iff BUG is defined for calc()
   cout << "0x" << hex << setfill('0') << value << endl;
#else
   // This code will never expose the bug
   cout << "0x" << hex << value << endl;
#endif
   if(value == 0x) {
  return 0;
   }
   else {
  return 1;
   }
}


int main()
{
   return CheckStuff();
}

The build line...

   gcc-3.4.1 -v -W -Wall -O3 -g2 gcc_bug.cpp

The results (it's purely random, but here's an example)...

   0x8048978bfffbb68

What it should print...

   0x

Observations...

   - Take out the -O3 (-O0) and it works
   - This program works just fine on Solaris no matter how you compile it
   - This program works with gcc 3.3.X, gcc 3.2.X and (shudder) 2.95
   - Take out setfill('0') and it works
   - Keep setfill('0') in the cout statement and return a tmp for the inline 
calc() function and it works

Compiler/system info...

system type:

   Linux x86 (RedHat Enterprise 3) 

gcc -v output:

--enable-shared --with-ld=//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-
linux2.4/bin/ld 

--with-as=//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/bin/as 

--with-nm=//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/bin/nm 

--enable-languages=c,c++,java --disable-nls
Thread model: posix
gcc version 3.4.1
 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/libexec/gcc/i686-pc-
linux-gnu/3.4

.1/cc1plus -quiet -v -D_GNU_SOURCE gcc_bug.cpp -quiet -dumpbase gcc_bug.cpp 

-mtune=pentiumpro -auxbase gcc_bug -g2 -O0 -W -Wall -version -o /tmp/cc82jgXc.s
ignoring nonexistent directory 

"//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-linux-
gnu/3.4.1/

../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-linux-
gnu/3.4.1/.

./../../../include/c++/3.4.1
 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-linux-
gnu/3.4.1/.

./../../../include/c++/3.4.1/i686-pc-linux-gnu
 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-linux-
gnu/3.4.1/.

./../../../include/c++/3.4.1/backward
 /usr/local/include
 //gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/include
 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-linux-
gnu/3.4.1/i

nclude
 /usr/include
End of search list.
GNU C++ version 3.4.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 //gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/bin/as -V -Qy -o /tmp/
cc15JK08.o 

/tmp/cc82jgXc.s
GNU assembler version 2.13.2.1 (i686-pc-linux-gnu) using BFD version 2.13.2.1
 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/libexec/gcc/i686-pc-
linux-gnu/3.4

.1/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -rpath 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib /usr/lib/crt1.o 

/usr/lib/crti.o 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-linux-
gnu/3.4.1/c

rtbegin.o 

-L//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-
linux-gnu/3.4.1 

-L//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-
linux-gnu/3.4.1

/../../../../i686-pc-linux-gnu/lib 

-L//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-
linux-gnu/3.4.1

/../../.. /tmp/cc15JK08.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc 

//gnu-gcc-3.4.1-binutils-2.13.2.1/i686-pc-linux2.4/lib/gcc/i686-pc-linux-
gnu/3.4.1/c

rtend.o /usr/lib/crtn.o

-- 
   Summary: setfill coupled with inline function: incorrect results
on Linux x86
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: knutejunk at austin dot rr dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18080] STL deque push_front, pop_front, push_back, and pop_back not O(1)

[ron at vaniwaarden dot org]

--- Additional Comments From ron at vaniwaarden dot org  2004-10-20 16:45 ---
(In reply to comment #1)
> Could you please have a look to libstdc++/13537? IMO, wither we should reopen
> that one or close both ;) Thanks.

Quoting from Sean Kirby in that discussion:

>> 23.2.1.3.3 says, "Inserting a single element either at the beginning or end
>> of a deque always takes constant time".

>> (Aside: Does the Standard mean true constant time there?

> 23.1/2 says, "All of the complexity requirements in this clause are stated
> solely in terms of the number of operations on the contained objects."

and then goes on to state:

> You are talking about complexity in terms of the number of operations
> performed on pointers to the contained objects.

If that is true, than inserting before an iterator in a singly linked list is
constant time since one only operates on list elements that contain the
elements.  Obviously, this is not true.  The fact that the implementation of the
deque uses an array of pointers to arrays of elements should excuse the behavior.

I agree that either 13537 should be reopened or this should be marked invalid. 
I don't believe the response to 13537 is sufficient to mark either invalid.

My understanding of big O notation is that for O(1) methods, the amount of time
to perform the operation should be independant of the number of elements in the
container.  The example I gave clearly shows that these methods can be linear in
the number of objects in the container.  One does not look at the number of
operations on elements of the container, one only looks at the total number of
operations performed in executing the method.

Again, I don't think there is an implementation which can meet the requirements
of the standard.  The current implementation is the standard implementation that
I have been able to find and does a good job when one is not doing bizare
behaviour as I demonstrate in the example.  However, it is not O(1).

-- 
   What|Removed |Added

  Component|libstdc++   |c++


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

[Bug ada/18085] New: [Ada] - C++ interoperability sample program fails, 3.4.2, Linux 2.4.20-8, Red Hat 9.0

[karl at grebyn dot com]

This program source is modified (additional print statements) from:
   
http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gnat_ugn_unw/A-Simple-Example.html#A-Simple-Example

An example of interoperating C++ and Ada code.  The results seem to
indicate that the calls between the two languages are working OK, but
that the parameter passing isn't.  I guess that indicates something in the ABI,
perhaps?

The final value in A::method2 should be 3030, and the intermediate
values in the Ada calls are wrong.

$ gcc -v
Reading specs from /opt/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ./configure --prefix=/opt --enable-languages=ada,c,c++
Thread model: posix
gcc version 3.4.2
$ uname -a
Linux ezekiel 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux
$ cat /etc/issue
Red Hat Linux release 9 (Shrike)
Kernel \r on an \m

$./cpp_main
in A::A, a_value = 1010
=== in A::method2, a_value was = 1010
in Ada_Method2, O_Value = 134582632
in Ada_Method2, A_Value =-1073749612
in A::method1, a_value = 2020
in Ada_Method2, O_Value = 134582632
in Ada_Method2, A_Value =-1073749612
in Ada_Method2, O_Value = 134582632
in Ada_Method2, A_Value = 3030
=== in A::method2, a_value = 2020
$ cat compile
#! /bin/csh
# compilation script to evidence the bug
gnatmake -c simple_cpp_interface
c++ -c cpp_main.C
c++ -c ex7.C
gnatbind -n simple_cpp_interface
gnatlink simple_cpp_interface -o cpp_main --LINK=c++  -lstdc++ ex7.o cpp_main.o
$ cat *.C *.h *.ad?
// cpp_main.C start

#include "ex7.h"
#include 

extern "C" {
  void adainit (void);
  void adafinal (void);
  void method1 (A *t);
}

void method1 (A *t)
{
t->method1 ();
}

int main ()
{
  A obj;
  adainit ();
  obj.method2 (3030);
  adafinal ();
}

// cpp_main.C end
//ex7.C start

#include "ex7.h"
#include 

extern "C" { void ada_method2 (A *t, int v);}

void A::method1 (void)
{
  a_value = 2020;
  printf ("in A::method1, a_value = %d \n",a_value);

}

void A::method2 (int v)
{
  printf ("=== in A::method2, a_value was = %d \n",a_value);
  ada_method2 (this, v);
  printf ("=== in A::method2, a_value = %d \n",a_value);

}

A::A(void)
{
  a_value = 1010;
  printf ("in A::A, a_value = %d \n",a_value);
}

//ex7.C end
// ex7.h start

class Origin {
 public:
  int o_value;
};

class A : public Origin {
 public:
  void method1 (void);
  virtual void method2 (int v);
  A();
  int a_value;
};

// ex7.h end
-- simple_cpp_interface.adb start
with Ada.Text_Io; use Ada.Text_Io;
package body Simple_Cpp_Interface is

procedure Ada_Method2 (This : in out A; V : Integer) is
   begin
  Ada.Text_Io.Put_Line ("in Ada_Method2, O_Value =" & Integer'Image
(This.O_Value));
  Ada.Text_Io.Put_Line ("in Ada_Method2, A_Value =" & Integer'Image
(This.A_Value));
  Method1 (This);
  Ada.Text_Io.Put_Line ("in Ada_Method2, O_Value =" & Integer'Image
(This.O_Value));
  Ada.Text_Io.Put_Line ("in Ada_Method2, A_Value =" & Integer'Image
(This.A_Value));
  This.A_Value := V;
  Ada.Text_Io.Put_Line ("in Ada_Method2, O_Value =" & Integer'Image
(This.O_Value));
  Ada.Text_Io.Put_Line ("in Ada_Method2, A_Value =" & Integer'Image
(This.A_Value));
   end Ada_Method2;

end Simple_Cpp_Interface;

-- simple_cpp_interface.adb end
-- simple_cpp_interface.ads start

package Simple_Cpp_Interface is
   type A is limited
  record
 O_Value : Integer;
 A_Value : Integer;
  end record;

pragma Convention (CPP, A);

procedure Method1 (This : in out A);
pragma Import (C, Method1);

procedure Ada_Method2 (This : in out A; V : Integer);
pragma Export (C, Ada_Method2);

end Simple_Cpp_Interface;

-- simple_cpp_interface.ads end

-- 
   Summary: [Ada] - C++ interoperability sample program fails,
3.4.2, Linux 2.4.20-8, Red Hat 9.0
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: karl at grebyn dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug rtl-optimization/18084] [3.4 only]setfill coupled with inline function: incorrect results on Linux x86

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 17:09 
---
It works on the mainline but not on 3.4.0 and I don't know if this is a regression.

But I should note that -O2 is enough and -O2 -fno-gcse works.

-- 
   What|Removed |Added

  Component|c++ |rtl-optimization
   Keywords||wrong-code
  Known to fail||3.4.0
  Known to work||4.0.0
Summary|setfill coupled with inline |[3.4 only]setfill coupled
   |function: incorrect results |with inline function:
   |on Linux x86|incorrect results on Linux
   ||x86
   Target Milestone|--- |3.4.3


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

[Bug c++/10841] rejects valid explicit type conversion to/from pointers-to-member of private base

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug fortran/18082] Excessively long compile time

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 17:15 
---
For some reason c1 and c2 are chained together in an infinite list.

-- 


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

[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 17:19 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|java|libgcj
 Ever Confirmed||1
  Known to fail||4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 17:19:39
   date||


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

[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().

[mnefedov at rogers dot com]

--- Additional Comments From mnefedov at rogers dot com  2004-10-20 17:33 ---
This could be a workaround. Do this: cal.setTime( cal.getTime() )

 before calling get( Calendar.DAY_OF_{YEAR|WEEK} );

Seems to fix the problem.



-- 


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

[Bug target/18032] [4.0.0] SH: wrong code for EH

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 17:39 
---
Fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug libgcj/13604] AccessController unfinished

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2004-10-20 17:44 ---
The patch will need to be updated for the new stack trace infrastructure,
because the interface to stack traces has changed. In particular, the
gnu.gcj.runtime.StackTrace class is no longer supported. 

Either a) we could add a native part to AccessController which calls the new
stack tracer, or b) if we want AccessController to remain pure Java, something
similar to the StackTrace class (but perhaps without a gcj-specific name) could
be put back in. Either way, this decision should be made in consulation with the
Classpath hackers so we all agree on the API between AccessController and the
stack tracer.


-- 


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

[Bug libgcj/13604] AccessController unfinished

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2004-10-20 17:45 ---
Actually using the native API is probably the better option, since having a
public stack trace API in Java is likely a security problem.

-- 


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

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2004-10-20 17:52 ---
Do we really want to fix this?

The "buggy" behaviour actually seems better here because it more closely matches
what other Java compilers do and seems to have resulted in less complaints from
users since it "broke". 

I propose we close this as WONTFIX and update the documentation to specify that
Utf8 is the default encoding for input files unless specified otherwise with the
--encoding flag. Comments?

-- 


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

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

[jsm at polyomino dot org dot uk]

--- Additional Comments From jsm at polyomino dot org dot uk  2004-10-20 17:59 
---
Subject: Re:  HAVE_LANGINFO_CODESET never defined

On Wed, 20 Oct 2004, mckinlay at redhat dot com wrote:

> Do we really want to fix this?
> 
> The "buggy" behaviour actually seems better here because it more closely matches
> what other Java compilers do and seems to have resulted in less complaints from
> users since it "broke". 
> 
> I propose we close this as WONTFIX and update the documentation to specify that
> Utf8 is the default encoding for input files unless specified otherwise with the
> --encoding flag. Comments?

I don't know what is best for Java, but for the C compiler POSIX specifies 
use of locale to determine the encoding of source files.  In addition, if 
HAVE_LANGINFO_CODESET were set properly then people using UTF-8 locales 
would get proper quotes in error messages.  If particular languages do not 
want this or don't work with it at present, they need not use the locale 
for source files, but the configure test should go in for the use of 
diagnostics if nothing else.

I understand Zack has proposals for changes to cpplib which would mean 
that for well-behaved locale character sets (supersets of ASCII, roughly) 
stray invalid characters in comments can be ignored rather than causing an 
error through not being in the locale character set (and speed up cpplib 
by not needing to pass most of most files through iconv).



-- 


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

[Bug rtl-optimization/18084] [3.4 only]setfill coupled with inline function: incorrect results on Linux x86

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-20 18:00 ---
Here's something slightly smaller: 
-- 
#include  
#include  
#include  
 
uint64_t mask1, mask2; 
 
uint64_t calc() { 
  return mask1 & mask2; 
} 
 
int main() 
{ 
  mask1 = 0xull; 
  mask2 = 0xull; 
  uint64_t value = calc(); 
 
  std::cout << std::setfill('0'); 
 
  if(value != calc()) 
abort (); 
} 
-- 
g/x> /home/bangerth/bin/gcc-3.4.3-pre/bin/c++ -O3 x.cc ; ./a.out  
Aborted 
 
I'll keep working on reducing this. 
 
W. 

-- 


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

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2004-10-20 18:03 
---
My understanding is that other java compilers do use the locale's
default encoding.  However, unlike the glibc iconv() converter, 
typically javac treats ASCII as equivalent to Latin 1.


-- 


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

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

[dennisc at harding dot ca]

--- Additional Comments From dennisc at harding dot ca  2004-10-20 18:04 ---
Created an attachment (id=7387)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7387&action=view)
preprocessed 6line file that triggers ICE

This is the preprocessor output of a minimal (6 line) file that triggers the
ICE.

-- 
   What|Removed |Added

Attachment #7232 is|0   |1
   obsolete||
Attachment #7233 is|0   |1
   obsolete||


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

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

[dennisc at harding dot ca]

--- Additional Comments From dennisc at harding dot ca  2004-10-20 18:06 ---
Created an attachment (id=7388)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7388&action=view)
gcc command and output for minimal test

This is the command line and compiler output produce with the new minimal
trigger file.

This file will compile if the command line option -mrenesas is removed.

-- 


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

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2004-10-20 18:10 ---
Forget what I said, Tom is right. I just tested this again, and javac from JDK
1.5 does indeed use the Locale setting to determine the default encoding.
Further more, javac does appear to distinguish between ASCII and Latin1 now. I
will re-test the patch and ping it to gcc-patches.

-- 


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

[Bug libgcj/18086] New: automate marking of Class object

[tromey at gcc dot gnu dot org]

Currently we have hand-written code to mark Class instances.
This is slow and is also bug-prone; we find problems in this
code with annoying frequency.  It may also be related to PR 16902.

It doesn't look hard to automate marking of Class.  Here is a plan:

* Rearrange fields of Class so that all marked fields are early,
  with non-marked fields later.

* Change gcj to emit a GC descriptor for Class.  Have the compiler
  abort() if a change is made to Class that causes us not to be able
  to make a GC descriptor.

* For all objects referenced by Class that are dynamically allocated,
  introduce a new descriptor kind at runtime.  Change how these objects
  are allocated, so that they will be marked by the GC and not by
  special code as a side effect of marking the class.  This should help
  the problem that Anthony noticed (see email message linked from PR 16902)

-- 
   Summary: automate marking of Class object
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug libgcj/18086] automate marking of Class object

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 18:27 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 18:27:53
   date||


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

[Bug target/18065] not using qi version of divmod

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-20 18:34 ---
Subject: Re:  wrong code emitted

Hi Andrew,

Please correct the failure mode description to " critical, wrong code",
as upon reviewing the avr.md file, it's now clear that this isn't a
"missed optimization"; GCC is failing to properly emit the instruction
explicitly matching it's specified QI mode operand constraints as specified
by a corresponding identically constrained C statement; more specifically:

(this behavior should be deterministic, and relies on no optimizations)

The explicit C declaration statement (which also fails for %):

signed char ss = (signed char)s / (signed char)s ;

Incorrectly emits an HI vs. QI mode instruction as specified avr.md

//uses <__divmodhi4> wrong, should be 8-bit <__divmodqi4>

  ce:99 81   lddr25, Y+1; 0x01
  d0:89 81   lddr24, Y+1; 0x01
  d2:28 2f   movr18, r24
  d4:33 27   eorr19, r19
  d6:27 fd   sbrcr18, 7
  d8:30 95   comr19
  da:89 2f   movr24, r25
  dc:99 27   eorr25, r25
  de:87 fd   sbrcr24, 7
  e0:90 95   comr25
  e2:b9 01   movwr22, r18
  e4:0e 94 81 01 call__divmodhi4
  e8:6b 83   stdY+3, r22; 0x03

Where the corresponding avr.md specifications are:

(define_expand "divmodqi4"
  [(set (reg:QI 24) (match_operand:QI 1 "register_operand" ""))
   (set (reg:QI 22) (match_operand:QI 2 "register_operand" ""))
   (parallel [(set (reg:QI 24) (div:QI (reg:QI 24) (reg:QI 22)))
  (set (reg:QI 25) (mod:QI (reg:QI 24) (reg:QI 22)))
  (clobber (reg:QI 22))
  (clobber (reg:QI 23))])
   (set (match_operand:QI 0 "register_operand" "") (reg:QI 24))
   (set (match_operand:QI 3 "register_operand" "") (reg:QI 25))]
  ""
  "")

(define_insn "*divmodqi4_call"
  [(set (reg:QI 24) (div:QI (reg:QI 24) (reg:QI 22)))
   (set (reg:QI 25) (mod:QI (reg:QI 24) (reg:QI 22)))
   (clobber (reg:QI 22))
   (clobber (reg:QI 23))]
  ""
  "%~call __divmodqi4"
  [(set_attr "type" "xcall")
   (set_attr "cc" "clobber")])


(define_expand "divmodhi4"
  [(set (reg:HI 24) (match_operand:HI 1 "register_operand" ""))
   (set (reg:HI 22) (match_operand:HI 2 "register_operand" ""))
   (parallel [(set (reg:HI 22) (div:HI (reg:HI 24) (reg:HI 22)))
  (set (reg:HI 24) (mod:HI (reg:HI 24) (reg:HI 22)))
  (clobber (reg:HI 26))
  (clobber (reg:QI 21))])
   (set (match_operand:HI 0 "register_operand" "") (reg:HI 22))
   (set (match_operand:HI 3 "register_operand" "") (reg:HI 24))]
  ""
  "")

(define_insn "*divmodhi4_call"
  [(set (reg:HI 22) (div:HI (reg:HI 24) (reg:HI 22)))
   (set (reg:HI 24) (mod:HI (reg:HI 24) (reg:HI 22)))
   (clobber (reg:HI 26))
   (clobber (reg:QI 21))]
  ""
  "%~call __divmodhi4"
  [(set_attr "type" "xcall")
   (set_attr "cc" "clobber")])

Which seems correct, but for some reason GCC is not able to recognize
when it's lhs operand is a QI mode operand when attempting to match
this specification when emitting code?

Thanks again, -paul-


> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 19 Oct 2004 20:39:44 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug target/18065] wrong built-in functions selected
> 
> 
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19
> 20:39 ---
> char ss = s % s ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
> This is not wrong as we sign extend the arguments as required by the C
> standard (to int).
> 
> So this is just an missed-optimization.
> 
> -- 
>What|Removed |Added
> 
>Severity|critical|minor
>   Component|c   |target
>Keywords||missed-optimization
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.




-- 


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

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

[dennisc at harding dot ca]

--- Additional Comments From dennisc at harding dot ca  2004-10-20 18:49 ---
This bug is triggered by calls to functions that return a char value combined
with the -mrenesas compiler option. Removing the compiler option, or changing
the functions return type to int will both eliminate the error. 

-- 


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

[Bug c/18065] usual arithmetic conversion not applying correctly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 18:50 
---
>From C99
(6.5.5/3): The usual arithmetic conversions are performed on the operands. 

6.3.1.8 Usual arithmetic conversions
Otherwise, the integer promotions are performed on both operands. Then the following 
rules are 
applied to the promoted operands: If both operands have the same type, then no further 
conversion is 
needed. Otherwise, if both operands have signed integer types or both have unsigned 
integer types, the 
operand with the type of lesser integer conversion rank is converted to the type of 
the operand with 
greater rank. Otherwise, if the operand that has unsigned integer type has rank 
greater or equal to the 
rank of the type of the other operand, then the operand with signed integer type is 
converted to the 
type of the operand with unsigned integer type. Otherwise, if the type of the operand 
with signed 
integer type can represent all of the values of the type of the operand with unsigned 
integer type, then 
the operand with unsigned integer type is converted to the type of the operand with 
signed integer 
type. Otherwise, both operands are converted to the unsigned integer type 
corresponding to the type of 
the operand with signed integer type. 

This is still not wrong code as signed char signed extended to int is still the same 
number but this is 
not a target problem but a front-end problem now.

To make sure that I read the statement correctly from the standard, it says if the 
types are the same 
there is no need to promote the value at all.

-- 
   What|Removed |Added

   Severity|minor   |normal
  Component|target  |c
Summary|not using qi version of |usual arithmetic conversion
   |divmod  |not applying correctly


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

[Bug libgcj/18087] New: Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[mnefedov at rogers dot com]

Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field -- it 
should not be adjusted.

Here is a sample code.

import java.util.Calendar;
import java.text.SimpleDateFormat;

public class CalendarTest2 {
public static void main( String [] args ) {

boolean fail = false;
Calendar c = Calendar.getInstance();
SimpleDateFormat df = new SimpleDateFormat( "E, 
-MM-dd [DDD] HH:mm:ss." );

System.out.println( "Today: " + df.format( c.getTime() ) );

c.set( 2004, 9, 1, 12, 0, 0 );
c.set( Calendar.MILLISECOND, 0 );
System.out.println( df.format( c.getTime() ) );

c.set( Calendar.DAY_OF_MONTH, 2 );
System.out.println( df.format( c.getTime() ) ); 

c.set( Calendar.DAY_OF_MONTH, 3 );
System.out.println( df.format( c.getTime() ) ); 


c.set( Calendar.DAY_OF_MONTH, 4 );
System.out.println( df.format( c.getTime() ) ); 
}
}

Here is the output with the errors:
1: Today: Wednesday, 2004-10-20 [294] 13:51:47.0592
2: Friday, 2004-10-01 [275] 13:00:00.
3: Saturday, 2004-10-02 [276] 13:00:00.
4: Sunday, 2004-10-03 [277] 12:00:00.
5: Monday, 2004-10-04 [278] 12:00:00.

Error #1: line 2:  hour was set to 12 not 13. What is interesting in this 
case -- c.get( Calendar.HOUR ) will give 12 back. SimpleDateFormat() report 13 
though.

Error #2: line 4: hour is 12 now.

-- 
   Summary: Calendar's HOUR field gets adjusted when setting
DAY_OF_MONTH field.
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mnefedov at rogers dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:00 
---
Confirmed on the mainline.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-10-20 19:00:50
   date||


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

[Bug libgcj/18088] New: Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[mnefedov at rogers dot com]

Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field -- it 
should not be adjusted.

Here is a sample code.

import java.util.Calendar;
import java.text.SimpleDateFormat;

public class CalendarTest2 {
public static void main( String [] args ) {

boolean fail = false;
Calendar c = Calendar.getInstance();
SimpleDateFormat df = new SimpleDateFormat( "E, 
-MM-dd [DDD] HH:mm:ss." );

System.out.println( "Today: " + df.format( c.getTime() ) );

c.set( 2004, 9, 1, 12, 0, 0 );
c.set( Calendar.MILLISECOND, 0 );
System.out.println( df.format( c.getTime() ) );

c.set( Calendar.DAY_OF_MONTH, 2 );
System.out.println( df.format( c.getTime() ) ); 

c.set( Calendar.DAY_OF_MONTH, 3 );
System.out.println( df.format( c.getTime() ) ); 


c.set( Calendar.DAY_OF_MONTH, 4 );
System.out.println( df.format( c.getTime() ) ); 
}
}

Here is the output with the errors:
1: Today: Wednesday, 2004-10-20 [294] 13:51:47.0592
2: Friday, 2004-10-01 [275] 13:00:00.
3: Saturday, 2004-10-02 [276] 13:00:00.
4: Sunday, 2004-10-03 [277] 12:00:00.
5: Monday, 2004-10-04 [278] 12:00:00.

Error #1: line 2:  hour was set to 12 not 13. What is interesting in this 
case -- c.get( Calendar.HOUR ) will give 12 back. SimpleDateFormat() report 13 
though.

Error #2: line 4: hour is 12 now.

-- 
   Summary: Calendar's HOUR field gets adjusted when setting
DAY_OF_MONTH field.
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mnefedov at rogers dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug libgcj/18088] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:05 
---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:05 
---
*** Bug 18088 has been marked as a duplicate of this bug. ***

-- 


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

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2004-10-20 19:07 ---
?? Pinskia: are you sure? This should be fixed already on mainline. Here's the
output I get with 4.0.0 20041019:

$ gij CalendarTest2
Today: Wednesday, 2004-10-20 [294] 15:05:28.0425
Friday, 2004-10-01 [275] 12:00:00.
Saturday, 2004-10-02 [276] 12:00:00.
Sunday, 2004-10-03 [277] 12:00:00.
Monday, 2004-10-04 [278] 12:00:00.


-- 


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

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:13 
---
Oh, you are right, what throw me off is the printing of todays date.  This is fixed on 
the mainline.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug c/18065] usual arithmetic conversion not applying correctly

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-20 19:14 ---
Subject: Re:  usual arithmetic conversion not applying
 correctly

Please read rule 1:

 "If both operands have the same type, then no further conversion is
  needed." (no promotion to int is specified or implied as being required)

Seems plain enough to me, what makes you think that:

  char + char  => int + int ?
 short + short => int + int ?

That would imply, QI mode (and HI mode typical of shorts on 32 bit machines)
rtl instruction definitions are meaningless which isn't the case; as their
definition defines the char and short operand rtl operator -> code
transformation.

The front end has no business promoting all char and short arithmetic
operands to ints, and in fact it doesn't; so am not sure what your thinking?

-paul-

> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 20 Oct 2004 18:50:01 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug c/18065] usual arithmetic conversion not applying correctly
> 
> 
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20
> 18:50 ---
> From C99
> (6.5.5/3): The usual arithmetic conversions are performed on the operands.
> 
> 6.3.1.8 Usual arithmetic conversions
> Otherwise, the integer promotions are performed on both operands. Then the
> following rules are
> applied to the promoted operands: If both operands have the same type, then no
> further conversion is
> needed. Otherwise, if both operands have signed integer types or both have
> unsigned integer types, the
> operand with the type of lesser integer conversion rank is converted to the
> type of the operand with
> greater rank. Otherwise, if the operand that has unsigned integer type has
> rank greater or equal to the
> rank of the type of the other operand, then the operand with signed integer
> type is converted to the
> type of the operand with unsigned integer type. Otherwise, if the type of the
> operand with signed
> integer type can represent all of the values of the type of the operand with
> unsigned integer type, then
> the operand with unsigned integer type is converted to the type of the operand
> with signed integer
> type. Otherwise, both operands are converted to the unsigned integer type
> corresponding to the type of
> the operand with signed integer type.
> 
> This is still not wrong code as signed char signed extended to int is still
> the same number but this is
> not a target problem but a front-end problem now.
> 
> To make sure that I read the statement correctly from the standard, it says if
> the types are the same
> there is no need to promote the value at all.
> 
> -- 
>What|Removed |Added
> 
>Severity|minor   |normal
>   Component|target  |c
> Summary|not using qi version of |usual arithmetic conversion
>|divmod  |not applying correctly
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.




-- 


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

[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:16 
---
This is a bug (at least by reading Sun's docs for Calendar).

-- 


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

[Bug c/18065] usual arithmetic conversion not applying correctly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:18 
---
But the front-end is doing the promotions where the problem comes from, nowhere else 
(I am using 
4.0 to verify my claim that the front-end is actually doing the promotion).

-- 


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

[Bug c/18065] usual arithmetic conversion not applying correctly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:25 
---
The promotion is coming from:
  if (convert_p)
{
  op0 = default_conversion (orig_op0);
  op1 = default_conversion (orig_op1);
}
  else
{
  op0 = orig_op0;
  op1 = orig_op1;
}

Maybe this should be changed 

-- 


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

[Bug c/18065] usual arithmetic conversion not applying correctly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:29 
---
And the reason why we don't shoten back to signed char % signed char:

  /* Although it would be tempting to shorten always here, that loses
 on some targets, since the modulo instruction is undefined if the
 quotient can't be represented in the computation mode.  We shorten
 only if unsigned or if dividing by something we know != -1.  */

So maybe this is correct.

-- 


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

[Bug c/18065] usual arithmetic conversion not applying correctly

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-20 19:33 ---
Subject: Re:  usual arithmetic conversion not applying
 correctly

Maybe the confusion is that you're not recognizing that:

char, short, int, long, long long, are all integer types, with different
storage formats.

As opposed to enum or bit-field for example which should likely be converted
to an "integer type" with ideally the smallest and/or most efficient
representation specified for the machine, prior to an "integer" oriented
operation being performed.

???

-paul-

> From: Paul Schlie <[EMAIL PROTECTED]>
> Date: Wed, 20 Oct 2004 15:14:08 -0400
> To: <[EMAIL PROTECTED]>
> Subject: Re: [Bug c/18065] usual arithmetic conversion not applying correctly
> 
> Please read rule 1:
> 
>  "If both operands have the same type, then no further conversion is
>   needed." (no promotion to int is specified or implied as being required)
> 
> Seems plain enough to me, what makes you think that:
> 
>   char + char  => int + int ?
>  short + short => int + int ?
> 
> That would imply, QI mode (and HI mode typical of shorts on 32 bit machines)
> rtl instruction definitions are meaningless which isn't the case; as their
> definition defines the char and short operand rtl operator -> code
> transformation.
> 
> The front end has no business promoting all char and short arithmetic operands
> to ints, and in fact it doesn't; so am not sure what your thinking?
> 
> -paul-
> 
>> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
>> Reply-To: <[EMAIL PROTECTED]>
>> Date: 20 Oct 2004 18:50:01 -
>> To: <[EMAIL PROTECTED]>
>> Subject: [Bug c/18065] usual arithmetic conversion not applying correctly
>> 
>> 
>> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20
>> 18:50 ---
>> From C99
>> (6.5.5/3): The usual arithmetic conversions are performed on the operands.
>> 
>> 6.3.1.8 Usual arithmetic conversions
>> Otherwise, the integer promotions are performed on both operands. Then the
>> following rules are
>> applied to the promoted operands: If both operands have the same type, then
>> no 
>> further conversion is
>> needed. Otherwise, if both operands have signed integer types or both have
>> unsigned integer types, the
>> operand with the type of lesser integer conversion rank is converted to the
>> type of the operand with
>> greater rank. Otherwise, if the operand that has unsigned integer type has
>> rank greater or equal to the
>> rank of the type of the other operand, then the operand with signed integer
>> type is converted to the
>> type of the operand with unsigned integer type. Otherwise, if the type of the
>> operand with signed
>> integer type can represent all of the values of the type of the operand with
>> unsigned integer type, then
>> the operand with unsigned integer type is converted to the type of the
>> operand 
>> with signed integer
>> type. Otherwise, both operands are converted to the unsigned integer type
>> corresponding to the type of
>> the operand with signed integer type.
>> 
>> This is still not wrong code as signed char signed extended to int is still
>> the same number but this is
>> not a target problem but a front-end problem now.
>> 
>> To make sure that I read the statement correctly from the standard, it says
>> if 
>> the types are the same
>> there is no need to promote the value at all.
>> 
>> -- 
>>What|Removed |Added
>> 
>>Severity|minor   |normal
>>   Component|target  |c
>> Summary|not using qi version of |usual arithmetic conversion
>>|divmod  |not applying correctly
>> 
>> 
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
>> 
>> --- You are receiving this mail because: ---
>> You reported the bug, or are watching the reporter.




-- 


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

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2004-10-20 19:36 ---
I've added a regression test based on this test case, to mauve's
gnu.testlet.java.util.Calendar.set

-- 


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

[Bug rtl-optimization/17450] Use of uninitialized data in reorder_insns

[drow at gcc dot gnu dot org]

--- Additional Comments From drow at gcc dot gnu dot org  2004-10-20 19:42 ---
Appears to be gone with current HEAD.  A number of new problems appeared, which
I will report separately.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug c/18065] usual arithmetic conversion not applying correctly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20 19:54 
---
When I am talking about promoting means that we add casts. aka sc%sc gets changed to 
(signed char) 
(((int)sc)%((int)sc)).

-- 


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

[Bug tree-optimization/18089] New: Valgrind errors in real.c

[drow at gcc dot gnu dot org]

During an --enable-checking=valgrind (and the normal checks) bootstrap, stage2
gives warnings compiling ggc-common.c.  The first one is:
==29462== Conditional jump or move depends on uninitialised value(s)
==29462==at 0x853CB22: do_fix_trunc (real.c:963)

963   if (REAL_EXP (r) <= 0)

(gdb) bt
#0  0x0853cb22 in do_fix_trunc (r=0x52bfd9cc, a=0x52bfd9b4) at
/home/drow/src/gcc/gcc/real.c:963
#1  0x0853e1be in real_trunc (r=0x52bfd9b4, mode=VOIDmode, x=0x7) at
/home/drow/src/gcc/gcc/real.c:4610
#2  0x0825fcaf in fold_convert_const (code=FIX_TRUNC_EXPR, type=0x1bb93488,
arg1=0x1c194a80)
at /home/drow/src/gcc/gcc/fold-const.c:1754
#3  0x080f9a0b in evaluate_stmt (stmt=Variable "stmt" is not available.
) at /home/drow/src/gcc/gcc/tree-ssa-ccp.c:853
#4  0x080fa0a8 in ccp_visit_stmt (stmt=0x1c191f54, taken_edge_p=0x7,
output_p=0x407)
at /home/drow/src/gcc/gcc/tree-ssa-ccp.c:1065
#5  0x08146f48 in simulate_stmt (stmt=0x1c191f54) at
/home/drow/src/gcc/gcc/tree-ssa-propagate.c:306
#6  0x081474f0 in ssa_propagate (visit_stmt=0x407, visit_phi=0x407)
at /home/drow/src/gcc/gcc/tree-ssa-propagate.c:429
#7  0x080fa77c in execute_ssa_ccp () at /home/drow/src/gcc/gcc/tree-ssa-ccp.c:1207

The code being compiled is the check of min_expand.  It looks like stage1 has
miscompiled stage2, because do_fix_trunc starts by copying *r to *a, but at this
read of *r r->uexp is still undefined.  That's just a guess.

Compiler is: GNU C version 4.0.0 20041012 (it took three days and a bit to do
the valgrind bootstrap).

-- 
   Summary: Valgrind errors in real.c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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