[Bug target/19704] ICE for tail call of regparm 3 and dllimport

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2005-05-16 07:52 ---
The patch in comment #3 isn't sufficient for cases where C++ class members get 
their dllimport status from attribute applied to class type, rather than from 
explicit attribute on the member.  This still fails with same error as original 
testcase:

// dllimport attribute applied to class type causes non-inline class members to 
// use dllimport indirect reference semantics

struct __declspec(dllimport)  Bar { 
  char* data;
  int getlen() const;
  char* getdata() const;
  void __attribute__ ((regparm(3))) assign(char*, int);  
};

struct Foo
{
Bar foobar;
void GetData();
};

void Foo::GetData()
{
foobar.assign(foobar.getdata(), foobar.getlen());
}



-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/20475] static_cast falsely allows const to be cast away

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-16 09:07 ---
Subject: Re:  static_cast falsely allows const to be cast away

"schlie at comcast dot net" <[EMAIL PROTECTED]> writes:

| --- Additional Comments From schlie at comcast dot net  2005-05-16 05:07 
---
| (In reply to comment #7)
| > Subject: Re:  static_cast falsely allows const to be cast away
| > That is your view.  However, not because GCC implements the ISO C++
| > view of types, means that GCC has a narrow view of a type is.  I
| > suspect that part of your speculation is based on unfamiliarity with
| > both the C++ type system and the GCC internal notion of types.
| 
| - but apparently inadequate to express the necessary differentiation between
|   constant and literal objects, as needed to be tracked by a compiler for
|   these languages?

I don't think the distinction is necessary -- I can see arguments why
people would want it, but it is not necessary.  You're speaking of
literals but seem to forget that 0 and 0+0 should be put in the
same category though the latter is not a literal. So, "literal" is not
the right thing.  The notion used in C++ is "constant expressions", that
directly leads to "const object"s.

| > | A literal string is not simply a 'const char [N]' object, as a
| > | literal value may not be specified as a target of an assignment,
| > | directly or indirectly though a pointer cast to a non-const object
| > | reference, unlike as a plain old 'const' objects may be.
| > 
| > But, a plain old 'const' object cannot be a target of an assignment.
| > There is no different there -- and certainly "static" does not imply a 
| > difference there -- so the basis of your argument seems fragile to
| > begin with.
| 
| - subtle possibly, but not fragile; the following simple program illustrates

without being insulting, I don't believe it is subtile -- it just
emphasizes some unfamiliarity with the C++ type system.  Once you
start adding a type qualifier, you have to spell out clearly its
interaction with the type system (including overload resolution) and
separate compilation. 

|   the problem, where if hypothetically 'literal' were a valid qualifier,
|   then the problem would be easy to solve, and also flexibly enable the

that "solve" is only apparent. It introduces a whole can of worms you
seem to handwave.

|   definition of functions which accept and return references to literals,
|   as being distinct from const, where const means simply not writeable
|   presently, not necessary never (i.e. can't ever assign to references,
|   which is what literal semantics would seem to dictate.):

But "const" in C++ does not mean "no writeable".  This is another
symptom of unfamiliarity with the C++ type system.

| #include 
| 
| int main (void)
| {
|// non-const pointers to literals should at least warn,
|// and assignments to literals should generate an error.
|char *cp = "(a)"; // compiles without warning/error (literal*)?

I have a warning on my system -- what are you using?

| // ((char *)cp)[1] = 't';// compiles without warning/error -> bus error!

because you shall not.  The rule is quite simple : thou shalt not
modify a const object.  No but, no if.  Period.

|printf(cp);   // dies above if uncommented, otherwise "(a)"
| 
|char ca[4] = "(b)";   // compiles without warning/error.
|((char *)ca)[1] = 't';// compiles without warning/error.
|printf(ca);   // outputs "(t)", as expected.

because of initialization of the array.

-- Gaby


-- 


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

[Bug c++/21510] Possible bug

[sven at clio dot in-berlin dot de]

--- Additional Comments From sven at clio dot in-berlin dot de  2005-05-16 
10:22 ---
(In reply to comment #7) 
> > Is there a way to distinguish between unions (which are not usable as base  
> > classes) and classes? If not, the standard is incomplete. 
>  
> You should know that 10 years ago people didn't even imagine the kind of 
> template usages that you are assuming as obvious. Indeed, everyone wants 
> to tell unions from classes now and you bet, it will be possible sometime 
> in the future, likely not using SFINAE at all. 
 
I know and accept this. SFINAE is a possible dangerous feature, anyway. It may 
be better if the ISO standard declares something like the following 
(incomplete, feel free to propose it to the standard comitee): 
 
The pragma statements 
 
_Pragme(set, "sfinae", on)   // enables SFINAE 
_Pragma(set, "sfinae", off)  // disables SFINAE 
_Pragma(reset, "sfinae") // sets SFINAE to the previous state 
 
control the substitution-failure-is-not-an-error-feature. When setting to "on" 
any substitution of a template argument of a class or function declared or 
defined in the context may fail without an error, if 
- the statement is syntactical correct 
- there is a less specific template which could be instantiated without an 
error. 
 
When leaving the context, _Pragma(reset, "sfinae") is called automatical. The 
user is complete responsible for using SFINAE, no further compiler support is 
standardized. 
 
This would localize the feature and alert the user that this is a potential 
dangerous construct. And it is much more general, possible easier to 
implement. 
 

-- 


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

[Bug tree-optimization/21448] [4.1 Regression] ICE in estimate_num_insns_1, at tree-inline.c:1433

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
11:25 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/18655] Incorrect data in .debug_frame section for PowerPC

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to work||4.0.1 4.1.0
   Target Milestone|4.1.0   |4.0.1


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

[Bug tree-optimization/21605] New: -Wunreachable-code wrong line number and multiple warnings for the same line

[alexander_herrmann at yahoo dot com dot au]

Some more on the 4.0.1 prerelease (gcc-4.0-20050507).
While trying to reproduce a problem with the -Wunreachable-code I stumbled of
this. Using the compiler Switches -O2 -O3 give the wrong Line number (25) of the
unused code and also repeats the error message 14 times. Using -Os gives the
right line number (29) and only one error message.  BTW not using optimization
doesn't give a warning message while there may be should be one.
[EMAIL PROTECTED] test]$ gcc -Wunreachable-code testcase_not_executed.c 
  
[EMAIL PROTECTED] test]$ 

[EMAIL PROTECTED] test]$ gcc -Os -Wunreachable-code testcase_not_executed.c 
testcase_not_executed.c: In Funktion ปmainซ:
testcase_not_executed.c:29: Warnung: wird niemals ausgefhrt
[EMAIL PROTECTED] test]$ 

[EMAIL PROTECTED] test]$ gcc -O2 -Wunreachable-code testcase_not_executed.c 
   
testcase_not_executed.c: In Funktion ปmainซ:
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:25: Warnung: wird niemals ausgefhrt
testcase_not_executed.c:29: Warnung: wird niemals ausgefhrt
[EMAIL PROTECTED] test]$ 

Here's the c source for this:
// reduced Testcase "code never gets executed"
// compiled with gcc  -Wunreachable-code -O3  
// Filename: testcase_not_executed.c
// Alexander J. Herrmann 16.05.2005  [EMAIL PROTECTED]
#include 
#include 
#include 

typedef int bool;
static char *aie_banner_head_refresh(void);


int main(void)
{
   char *sptr = aie_banner_head_refresh();
   printf("%s\n", sptr); 
 
   return(0);
}

static char *aie_banner_head_refresh(void)
{
   static char adKategorie[10];
   char *isAdKategorie = NULL;
   memset(adKategorie, '!', sizeof(adKategorie));
   *(adKategorie + sizeof(adKategorie)-1) = '\0'; // so nobody can complain 
   if (isAdKategorie != NULL)
   {
  strncpy(adKategorie, isAdKategorie, sizeof(adKategorie)-1);
   }
   return(adKategorie);
}

-- 
   Summary: -Wunreachable-code wrong line number and multiple
warnings for the same line
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexander_herrmann at yahoo dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug tree-optimization/21605] -Wunreachable-code wrong line number and multiple warnings for the same line

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
11:50 ---
This is a bug in glibc's headers which inlines memset.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgcj/21606] New: java.net.URI fails to decode lowercase hex codes

[brion at pobox dot com]

URIs may contain special hexadecimal byte codes in the format %HH where H is a
hexadecimal digit, either upper or lowercase. (RFC 2396 2.4.1)

When given a string containing lowercase hex codes such as %2c, the URI
constructor throws a URISyntaxException.

Steps to reproduce:
1. new URI("/a%2cb")

Actual results:
A URISyntaxException is thrown.

Expected results:
A happy, usable URI object. This works as expected on Sun's JDK 1.5.0.

Additional information:
GCC 4.0 compiled from source release on an Ubuntu Linux 5.04 "Hoary" system.

-- 
   Summary: java.net.URI fails to decode lowercase hex codes
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brion at pobox dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs 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=21606

[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
11:59 ---
Subject: Bug 20270

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-16 11:58:49

Modified files:
gcc/ada: Makefile.in ChangeLog 

Log message:
PR ada/20270
* Makefile.in: Make TGT_LIB behave correctly.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gcc&r1=1.116&r2=1.117
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.662&r2=1.663



-- 


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

[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols

[neroden at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
11:59 ---
Subject: Bug 20270

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-16 11:58:49

Modified files:
gcc/ada: Makefile.in ChangeLog 

Log message:
PR ada/20270
* Makefile.in: Make TGT_LIB behave correctly.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gcc&r1=1.116&r2=1.117
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.662&r2=1.663


--- Additional Comments From neroden at gcc dot gnu dot org  2005-05-16 
11:59 ---
Committed fix to mainline. 

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libgcj/21606] java.net.URI fails to decode lowercase hex codes

[brion at pobox dot com]

--- Additional Comments From brion at pobox dot com  2005-05-16 12:00 
---
Created an attachment (id=8899)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8899&action=view)
Test case

$ javac UriBugDemo.java && java UriBugDemo
ok: /a,b
ok: /a%2C,b
ok: /a%2c,b

$ gcj-4.0 -o UriBugDemo --main=UriBugDemo UriBugDemo.java && ./UriBugDemo
ok: /a,b
ok: /a%2C,b
broke! /a%2c,b


-- 


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

Bugs

[akshyaya kumar]

Hi..
I am facing problem, when i am going for installing in
the binutil 2.13.1 for the target powerpc.eabi , GNU
cross compiler for ecos.

These are the following bugs are coming at the Build
and install the GNU binary utilities:


make -w all install 2>&1 | tee make.out 

After giving this command this error is came.


Error:

make: Entering directory `/tmp/build/binutils'
make[1]: Entering directory
`/tmp/build/binutils/libiberty'
make[2]: Entering directory
`/tmp/build/binutils/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/tmp/build/binutils/libiberty/testsuite'
make[1]: Leaving directory
`/tmp/build/binutils/libiberty'
make[1]: Entering directory `/tmp/build/binutils/intl'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/build/binutils/intl'
make[1]: Entering directory `/tmp/build/binutils/bfd'
make  all-recursive
make[2]: Entering directory `/tmp/build/binutils/bfd'
Making all in doc
make[3]: Entering directory
`/tmp/build/binutils/bfd/doc'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/tmp/build/binutils/bfd/doc'
Making all in po
make[3]: Entering directory
`/tmp/build/binutils/bfd/po'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/tmp/build/binutils/bfd/po'
make[3]: Entering directory `/tmp/build/binutils/bfd'
make[3]: Leaving directory `/tmp/build/binutils/bfd'
make[2]: Leaving directory `/tmp/build/binutils/bfd'
make[1]: Leaving directory `/tmp/build/binutils/bfd'
make[1]: Entering directory
`/tmp/build/binutils/opcodes'
make  all-recursive
make[2]: Entering directory
`/tmp/build/binutils/opcodes'
Making all in po
make[3]: Entering directory
`/tmp/build/binutils/opcodes/po'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/tmp/build/binutils/opcodes/po'
make[3]: Entering directory
`/tmp/build/binutils/opcodes'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory
`/tmp/build/binutils/opcodes'
make[2]: Leaving directory
`/tmp/build/binutils/opcodes'
make[1]: Leaving directory
`/tmp/build/binutils/opcodes'
make[1]: Entering directory
`/tmp/build/binutils/binutils'
make  all-recursive
make[2]: Entering directory
`/tmp/build/binutils/binutils'
Making all in doc
make[3]: Entering directory
`/tmp/build/binutils/binutils/doc'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/tmp/build/binutils/binutils/doc'
Making all in po
make[3]: Entering directory
`/tmp/build/binutils/binutils/po'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/tmp/build/binutils/binutils/po'
make[3]: Entering directory
`/tmp/build/binutils/binutils'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory
`/tmp/build/binutils/binutils'
make[2]: Leaving directory
`/tmp/build/binutils/binutils'
make[1]: Leaving directory
`/tmp/build/binutils/binutils'
make[1]: Entering directory `/tmp/build/binutils/etc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/build/binutils/etc'
make[1]: Entering directory `/tmp/build/binutils/gas'
make  all-recursive
make[2]: Entering directory `/tmp/build/binutils/gas'
Making all in doc
make[3]: Entering directory
`/tmp/build/binutils/gas/doc'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/tmp/build/binutils/gas/doc'
Making all in po
make[3]: Entering directory
`/tmp/build/binutils/gas/po'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/tmp/build/binutils/gas/po'
make[3]: Entering directory `/tmp/build/binutils/gas'
gcc -DHAVE_CONFIG_H -I. -I/src/binutils-2.13.1/gas -I.
-D_GNU_SOURCE -I. -I/src/binutils-2.13.1/gas -I../bfd
-I/src/binutils-2.13.1/gas/config
-I/src/binutils-2.13.1/gas/../include
-I/src/binutils-2.13.1/gas/..
-I/src/binutils-2.13.1/gas/../bfd
-I/src/binutils-2.13.1/gas/../intl -I../intl
-DLOCALEDIR="\"/gnutools/share/locale\""   -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -g -O2 -c
/src/binutils-2.13.1/gas/config/tc-ppc.c
/src/binutils-2.13.1/gas/config/tc-ppc.c: In function
`md_assemble':
/src/binutils-2.13.1/gas/config/tc-ppc.c:2188:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:2190:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:2195:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:2197:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:2202:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:2204:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:2209:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:2211:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c: In function
`md_apply_fix3':
/src/binutils-2.13.1/gas/config/tc-ppc.c:5404:
warning: right shift count >= width of type
/src/binutils-2.13.1/gas/config/tc-ppc.c:5411:
warning: right shift count >

[Bug target/19704] ICE for tail call of regparm 3 and dllimport

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |4.0.1


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

[Bug tree-optimization/21591] not vectorizing a loop with access to structs

[aph at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||aph at gcc dot gnu dot org


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

[Bug java/21428] [3.4/4.0/4.1 Regression] bogus warning: unused parameter 'this'

[aph at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|NEW |WAITING


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

[Bug target/21535] Empty inline assembly cause the generated code to be wrong?

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-05-16 
13:07 ---
You say that p.s doesn't work.  Could you explain why?  The code appears
to be functionally identical to q.s, the only difference being that p.s
allows the assembler to reorder the code and q.s does not.

The effect of an asm is deliberate.  gcc normally tries to put the
whole function inside a ".set noreorder/.set nomacro" block.
But it isn't safe to put asms in such a block because they might
use assembler macros.


-- 
   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug target/21472] Gcc generates CALL16 reloc that ld objects to

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-05-16 
13:11 ---
Andrew's right.  You're telling gcc that init_fallthru() and fini_fallthru()
are global functions, but your asms define it to be a local function.


-- 
   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/20475] static_cast falsely allows const to be cast away

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-05-16 13:25 
---
(In reply to comment #9)
Subject: Re:  static_cast falsely allows const to be cast away

> Gabriel Dos Reis writes:
>| --- Additional Comments From schlie at comcast dot net  2005-05-16
>| (In reply to comment #7)
>| > Subject: Re:  static_cast falsely allows const to be cast away
>| > That is your view.  However, not because GCC implements the ISO C++
>| > view of types, means that GCC has a narrow view of a type is.  I
>| > suspect that part of your speculation is based on unfamiliarity with
>| > both the C++ type system and the GCC internal notion of types.
>| 
>| - but apparently inadequate to express the necessary differentiation
>|   between constant and literal objects, as needed to be tracked by a
>|   compiler for these languages?
>
> I don't think the distinction is necessary -- I can see arguments why
> people would want it, but it is not necessary.  You're speaking of
> literals but seem to forget that 0 and 0+0 should be put in the
> same category though the latter is not a literal. So, "literal" is not
> the right thing.  The notion used in C++ is "constant expressions", that
> directly leads to "const object"s.

- to me "constant expression" is an oxymoron, as any expression which can't
  be resolved to a literal value prior to program execution is a runtime
  "computed" expression. (so all expressions resolve at compile time to
  either literals or otherwise, where the "otherwise"s may result in
  'const' objects and/or references or not.

>| > | A literal string is not simply a 'const char [N]' object, as a
>| > | literal value may not be specified as a target of an assignment,
>| > | directly or indirectly though a pointer cast to a non-const object
>| > | reference, unlike as a plain old 'const' objects may be.
>| > 
>| > But, a plain old 'const' object cannot be a target of an assignment.
>| > There is no different there -- and certainly "static" does not imply a 
>| > difference there -- so the basis of your argument seems fragile to
>| > begin with.
>| 
>| - subtle possibly, but not fragile; the following simple program illustrates
>
> without being insulting, I don't believe it is subtile -- it just
> emphasizes some unfamiliarity with the C++ type system.  Once you
> start adding a type qualifier, you have to spell out clearly its
> interaction with the type system (including overload resolution) and
> separate compilation. 

- no worries; yes I simply believe attempting to capture the necessary
  subtleties of literal objects and references imply the necessity of
  a distinct qualifier, although not necessary in the source language, as
  literal objects are declared by context and syntax, not by explicitly
  typed declaration.

>|   the problem, where if hypothetically 'literal' were a valid qualifier,
>|   then the problem would be easy to solve, and also flexibly enable the
>
> that "solve" is only apparent. It introduces a whole can of worms you
> seem to handwave.

- I admit some "hand-waving", but would be pleased to try to be more
  specific, if you could point out a more specific complexity which it
  introduces? (as I've already tried to point out issues that it helps
  resolve for which 'const' is not sufficiently differentiating.)

>|   definition of functions which accept and return references to literals,
>|   as being distinct from const, where const means simply not writeable
>|   presently, not necessary never (i.e. can't ever assign to references,
>|   which is what literal semantics would seem to dictate.):
>
> But "const" in C++ does not mean "no writeable".  This is another
> symptom of unfamiliarity with the C++ type system.

- I believe I understand that 'const' implies a set of semantics depending
  on the context of the object's use; one of which relate to the ability to
  modify it's value directly and/or indirectly dependant on the objects then
  current contextual 'const' qualification. Which I attempt to differentiate
  from literal objects, which have so such valid disqualification.

>| #include 
>| 
>| int main (void)
>| {
>|// non-const pointers to literals should at least warn,
>|// and assignments to literals should generate an error.
>|char *cp = "(a)"; // compiles without warning/error (literal*)?
>
> I have a warning on my system -- what are you using?

- sorry, actually complied using C on the most current tools for OSX 10.3.9.

>| // ((char *)cp)[1] = 't';// compiles without warning/error -> bus error!
>
> because you shall not.  The rule is quite simple : thou shalt not
> modify a const object.  No but, no if.  Period.

- but does compile without error?

  (because once assigned to a pointer GCC couldn't differentiate between
   a 'const' reference which may be potentially validly cast away, and a
   literal reference which may never be validly cast away?)

>|printf(cp);   // dies above if uncommented, otherwise "(a

[Bug c/21607] New: Optimizations convert 0 to -0 leading to difference in answers.

[fsmith at mathworks dot com]

Hi,

Sorry for the missing information above.  gcc -v did not supply the above 
information and for reasons unknown to me gccbug was not installed on the 
system in question.

Compiling with -O changes the results of this program.

double u_im = 0;

extern double atan(double);
extern int printf(const char *str,...);

int main(void)
{
double y;
double b;

/* Becomes -0 with optimizations and 0 without. */
b = 0 - 3*u_im;

y = atan(-7/b);

printf("b = %g\n",b);
printf("atan(-7/b) = %g\n",y);

if(y >= 0) {
printf("Error happened!\n");
}

return (y>=0);
}

-- 
   Summary: Optimizations convert 0 to -0 leading to difference in
answers.
   Product: gcc
   Version: 3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fsmith at mathworks dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21607] Optimizations convert 0 to -0 leading to difference in answers.

[fsmith at mathworks dot com]

--- Additional Comments From fsmith at mathworks dot com  2005-05-16 13:48 
---
Created an attachment (id=8901)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8901&action=view)
Minimal self-contained C program exhibiting problem

The answer provided by this program changes depending on whether or
not optimizations are turned on.

The reason for the difference is that the value b changes between 0
and -0 depending on the optimization level.

Here is some sample output:
% gcc emtst_asinh_standalone.c
b = 0
atan(-7/b) = -1.5708
% gcc -O emtst_asinh_standalone.c
b = -0
atan(-7/b) = 1.5708
Error happened!


-- 


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

[Bug c/21607] Optimizations convert 0 to -0 leading to difference in answers.

[fsmith at mathworks dot com]

--- Additional Comments From fsmith at mathworks dot com  2005-05-16 13:49 
---
Created an attachment (id=8902)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8902&action=view)
Pre-processed version of previous attachment.

Preprocessed version of previous file.  The previous C file was self-contained
so the only benefit you got was deleting my comments.

-- 


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

[Bug c/21607] Optimizations convert 0 to -0 leading to difference in answers.

[fsmith at mathworks dot com]

--- Additional Comments From fsmith at mathworks dot com  2005-05-16 13:50 
---
Information from gcc -save-temps -v follows:

Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
 /usr/libexec/gcc/darwin/ppc/3.3/cc1 -E -quiet -v -D__GNUC__=3 -
D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1495 -D__DYNAMIC__ 
emtst_asinh_standalone.c -fPIC -O emtst_asinh_standalone.i
ignoring nonexistent directory "/usr/ppc-darwin/include"
ignoring nonexistent directory "/Local/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/include/gcc/darwin/3.3
 /usr/include
End of search list.
Framework search starts here:
 /System/Library/Frameworks
 /Library/Frameworks
End of framework search list.
 /usr/libexec/gcc/darwin/ppc/3.3/cc1 -fpreprocessed emtst_asinh_standalone.i -
fPIC -quiet -dumpbase emtst_asinh_standalone.c -auxbase 
emtst_asinh_standalone -O -version -o emtst_asinh_standalone.s
GNU C version 3.3 20030304 (Apple Computer, Inc. build 1495) (ppc-darwin)
compiled by GNU C version 3.3 20030304 (Apple Computer, Inc. build 
1495).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=131072
 /usr/libexec/gcc/darwin/ppc/as -arch ppc -o emtst_asinh_standalone.o 
emtst_asinh_standalone.s
 ld -arch ppc -dynamic -o a.out -lcrt1.o -lcrt2.o -L/usr/lib/gcc/darwin/3.3 -
L/usr/lib/gcc/darwin -L/usr/libexec/gcc/darwin/ppc/3.3/../../.. 
emtst_asinh_standalone.o -lgcc -lSystem |
 c++filt3


-- 
   What|Removed |Added

  GCC build triplet||1495


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

[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-05-16 
13:52 ---
It's a problem of tree-lowering.  In .t02.original we still have

  return  = (int) (a && b);

in .t03.generic it's

bool doAnd(bool, bool) (a, b)
{
  int D.1578;
  bool iftmp.0;
  bool D.1582;
  bool D.1583;

  D.1582 = !a;
  if (D.1582)
{
  goto ;
}
  else
{

}
  D.1583 = !b;
  if (D.1583)
{
  goto ;
}
  else
{

}
  iftmp.0 = 1;
  goto ;
  :;
  iftmp.0 = 0;
  :;
  D.1578 = (int) iftmp.0;
  return D.1578;
}


Note that changing the function to

bool f(bool b1, bool b2) { int b1i = b1; int b2i = b2; return (!!b1i && !!b2i); 
}

results in the much better

bool manualAnd(bool, bool) (a, b)
{
  int D.1590;
  bool D.1591;
  bool D.1592;
  bool D.1593;
  
  {
int ai;
int bi;

ai = (int) a;
bi = (int) b;
D.1591 = ai != 0;
D.1592 = bi != 0;
D.1593 = D.1591 && D.1592;
D.1590 = (int) D.1593;
return D.1590;
  }
}


-- 


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

[Bug c/21607] Optimizations convert 0 to -0 leading to difference in answers.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
13:53 ---
This is a bug in Apple's GCC, it uses fmadd instructions when it is not safe, 
please report this to Apple, 
I think it is fixed in Apple's 4.0.0 GCC based compiler.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/15484] [tree-ssa] bool and short function arguments promoted to int

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-05-16 
13:55 ---
Maybe the same problem results in

static inline bool wrap(bool f) { return f; }
bool bar(bool f)
{
return wrap(f);
}

producing

  return (int) (bool) (int) (bool) (int) f;

(and more, if you add another wrap())

-- 


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

[Bug tree-optimization/21608] New: Repeated casts between bool and int are not optimized

[rguenth at gcc dot gnu dot org]

Consider the testcase

static inline bool wrap(bool f) { return f; }
bool bar(bool f)
{
return wrap(f);
}

we have in t67.optimized

  return (int) (bool) (int) (bool) (int) f;

and in t14.oplower

bool bar(bool) (f)
{
  int D.1592;
  bool f;
  bool D.1583;
  int D.1582;
  int D.1581;
  int D.1591;

:
  D.1582 = (int) f;
  f = (bool) D.1582;
  D.1592 = (int) f;
  D.1591 = D.1592;
  D.1583 = (bool) D.1591;
  D.1581 = (int) D.1583;
  return D.1581;

}

this load of SSA variables must pessimize or at least slow down something.

-- 
   Summary: Repeated casts between bool and int are not optimized
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90

[joel at oarcorp dot com]

--- Additional Comments From joel at oarcorp dot com  2005-05-16 14:00 
---
Subject: Re:  Segfault while compiling 
libgfortran/intrinsics/selected_int_kind.f90

corsepiu at gcc dot gnu dot org wrote:
> --- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-14 
> 08:33 ---
> (In reply to comment #16)
> 
>>Subject: Re:  Segfault while compiling
> 
> libgfortran/intrinsics/selected_int_kind.f90
> 
>>
>>On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote:
>>
>>
>>>* f95 disqualifies ifselves from several embedded targets, if it can 
>>>not be
>>>built/used on targets not supporting REAL8. IIRC, there even exist 
>>>variants of
>>>major _targets_ (IIRC, powerpc, m68k) which do not support REAL8.
>>>IMO, this is a design flaw, which should be in your interest to be 
>>>circumvented.
>>
>>Huh, PPC soft float supports REAL 8 still.
> 
> 
> Joel, do you recall the target in RTEMS which has 4-byte floats only?
> (We recently had an issue with it floating point context sizes related to it?
> IIRC, it had been a powerpc variant and we were forced to drop it because GCC
> doesn't support it.

I don't know of any specific models.  The code in RTEMS was based upon 
an early (mid-90's) version of the PowerPC Programming Environments 
Manual.  I recall that version of the manual as being clear that a 
single precision PowerPC was possible within the architectural definition.

I just downloaded the current one from FreeScale and I see no hint that
this architectural option is allowed anymore.

> BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't
> have 8byte floats. RTEMS doesn't support them, so I've never tried to build
> fortran for then.

--joel


-- 


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

[Bug tree-optimization/21608] Repeated casts between bool and int are not optimized

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
14:02 ---
Confirmed, this is mostly a tree combiner issue, but trying on the stupid 
version of the tree combiner it 
does not work, I don't know why yet.

-- 
   What|Removed |Added

  BugsThisDependsOn||15459
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||TREE
   Last reconfirmed|-00-00 00:00:00 |2005-05-16 14:02:32
   date||


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

[Bug c/21607] Optimizations convert 0 to -0 leading to difference in answers.

[fsmith at mathworks dot com]

--- Additional Comments From fsmith at mathworks dot com  2005-05-16 14:04 
---
How do I report it to Apple?  On their site

http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/gccbug.html#gccbug

they told me to report it here (effectively).  But since, for reasons unknown to
me, gccbug wasn't installed on the MAC I was using I went straight to bugzilla.

-Fred

-- 


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

[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-16 
14:05 ---
(In reply to comment #24)
> Subject: Re:  Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
> 
> corsepiu at gcc dot gnu dot org wrote:
> 
> > Joel, do you recall the target in RTEMS which has 4-byte floats only?
I've found it. The RTEMS sources claim the "PowerPC 602" to have 4byte floats,
only. 

> Note that the major demand the Fortran Standard places on DOUBLE 
> PRECISION is that it takes up twice the amount of storage.  It also is 
> supposed to be of "higher precision", but that is a QOI issue.

Cf. gcc-4.0-branch/fortran/trans-types.c ca. line 228ff:

  /* F95 14.6.3.1: A nonpointer scalar object of type double precision
 real ... occupies two contiguous numeric storage units.
...
  .. But at present there are
 no GCC targets for which a two-word type does not exist, so we
 just let gfc_validate_kind abort and tell us if something breaks.  */

Well, the h8300 has 8byte types (seemingly long long), but it doesn't have 8byte
floats. As the comment is on REAL8, ... there is something fishy in there.

-- 


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

[Bug c/21607] Optimizations convert 0 to -0 leading to difference in answers.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
14:08 ---
(In reply to comment #5)
> How do I report it to Apple?  On their site
> 
> http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/gccbug.html#gccbug

http://bugreport.apple.com

-- 


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

[Bug java/20044] Wrong method call semantics (maybe instanceof/invokespecial)

[aph at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aph at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-05-16 15:48 ---
Bug 21382 is a duplicate of bug 19664, which also requires the libstdc++
change.

-- 


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

[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs

[mark at gcc dot gnu dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2005-05-16 16:03 
---
The paperwork cleared with the FSF.
There was a glitch in the new "fully-automatic" system.
Apologies.

-- 


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

[Bug libstdc++/21609] New: array_allocator vs rebind & copy-constructor

[pcarlini at suse dot de]

There is an issue with array_allocator, which clearly surfaced while working
on libstdc++/19495. In a nutshell, the templated copy-constructor doesn't seem 
to
play well with rebinds: after a rebind, the first copy-constructor call leads
to _M_array = 0 and no memory can be possibly returned by allocate. This makes
sense, because the underlying array probably is inappropriate for a type !=
the orginal one (because of alignment requirements, at least), but leads to an
allocator much less usable in general applications.

-- 
   Summary: array_allocator vs rebind & copy-constructor
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: bkoz at redhat dot com,gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/21609] array_allocator vs rebind & copy-constructor

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-16 16:30 
---
Forgot to say: probably the issue can be dealt with at the cost of increasing
its complexity. Logic could be added to the copy-constructor(s) to the effect
of keeping on using the existing allocated memory, i.e., not zeroing _M_array
in the templated copy-contructor. This would make sense only when the alignment
is still appropriate for the new type: this check could be either responsability
of the user or enforced by the allocator (more tricky).

-- 


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

[Bug c++/20475] static_cast falsely allows const to be cast away

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-16 17:00 ---
Subject: Re:  static_cast falsely allows const to be cast away

"schlie at comcast dot net" <[EMAIL PROTECTED]> writes:

| (In reply to comment #9)
| Subject: Re:  static_cast falsely allows const to be cast away
| 
| > Gabriel Dos Reis writes:
| >| --- Additional Comments From schlie at comcast dot net  2005-05-16
| >| (In reply to comment #7)
| >| > Subject: Re:  static_cast falsely allows const to be cast away
| >| > That is your view.  However, not because GCC implements the ISO C++
| >| > view of types, means that GCC has a narrow view of a type is.  I
| >| > suspect that part of your speculation is based on unfamiliarity with
| >| > both the C++ type system and the GCC internal notion of types.
| >| 
| >| - but apparently inadequate to express the necessary differentiation
| >|   between constant and literal objects, as needed to be tracked by a
| >|   compiler for these languages?
| >
| > I don't think the distinction is necessary -- I can see arguments why
| > people would want it, but it is not necessary.  You're speaking of
| > literals but seem to forget that 0 and 0+0 should be put in the
| > same category though the latter is not a literal. So, "literal" is not
| > the right thing.  The notion used in C++ is "constant expressions", that
| > directly leads to "const object"s.
| 
| - to me "constant expression" is an oxymoron,

then, you're out of luck.

[...]

| >|   definition of functions which accept and return references to literals,
| >|   as being distinct from const, where const means simply not writeable
| >|   presently, not necessary never (i.e. can't ever assign to references,
| >|   which is what literal semantics would seem to dictate.):
| >
| > But "const" in C++ does not mean "no writeable".  This is another
| > symptom of unfamiliarity with the C++ type system.
| 
| - I believe I understand that 'const' implies a set of semantics depending
|   on the context of the object's use; one of which relate to the ability to
|   modify it's value directly and/or indirectly dependant on the objects then
|   current contextual 'const' qualification. Which I attempt to differentiate
|   from literal objects, which have so such valid disqualification.
| 
| >| #include 
| >| 
| >| int main (void)
| >| {
| >|// non-const pointers to literals should at least warn,
| >|// and assignments to literals should generate an error.
| >|char *cp = "(a)"; // compiles without warning/error (literal*)?
| >
| > I have a warning on my system -- what are you using?
| 
| - sorry, actually complied using C on the most current tools for OSX 10.3.9.

If you fill a PR about C++ while you're testing C, you do not expect
anything useful out it.  Do you?  Anyway, you do get a warning with
both C and C++ front-end if you say -Wwrite-strings.

[...]

| (or are you asserting that in C++ unlike C, 'const' objects are all literal
|  values, who's values are never allocated and subsequently computed and/or
|  modified at run-time, which doesn't seem to be purely the case?)

I'm claiming that
  (1) "const" has a different semantics in C++ than in C.
  (2) const objects cannot be modified in C++ -- if you do, you get
  what you deserve.
  (3) in C++, const objects initialized with constant expressions, can
  participate in constant expressions.  Consequently, if their
  addresses are never taken, the compiler will not allocate
  storage for them.  G++ has been doing that optimization for ages
  now.  Notice that, that differs from C.

-- Gaby


-- 


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

[Bug libstdc++/21609] array_allocator vs rebind & copy-constructor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
17:41 ---
Templates are never copy constructors.

-- 


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

[Bug libstdc++/21609] array_allocator vs rebind & templated constructor

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-16 17:51 
---
Yes, sorry ;) (12.8). Summary fixed.

-- 
   What|Removed |Added

Summary|array_allocator vs rebind & |array_allocator vs rebind &
   |copy-constructor|templated constructor


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

[Bug target/21588] x86 machine builtins do not have any const/pure attributes set

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-05-16 18:14 
---
True.  I remember trying this, though, and in practice all it did was increase
register pressure.

-- 


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

[Bug target/21556] [4.0/4.1 Regression] TLS failures on 4.0 branch

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
18:23 ---
Subject: Bug 21556

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-16 18:22:50

Modified files:
gcc: ChangeLog 
gcc/config/ia64: ia64.md 

Log message:
PR target/21556
* config/ia64/ia64.md (load_dtpmod, load_ltoff_dtpmod, load_dtprel,
load_dtprel64, load_dtprel22, load_dtprel_gd, load_ltoff_dtprel,
add_dtprel, add_dtprel14, add_dtprel22, load_tprel, load_tprel64,
load_tprel22, load_tprel_ie, load_ltoff_tprel, add_tprel, add_tprel14,
add_tprel22): Remove mode from symbolic operand.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8802&r2=2.8803
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&r1=1.152&r2=1.153



-- 


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

[Bug libstdc++/21609] array_allocator vs rebind & templated constructor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
18:24 ---
(In reply to comment #2)
> Templates are never copy constructors.

Just to clarify just in case some mistakes this for something different.
template member functions cannot be considered a copy constructor.

-- 


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

[Bug target/21556] [4.0/4.1 Regression] TLS failures on 4.0 branch

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
18:26 ---
Subject: Bug 21556

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-16 18:25:50

Modified files:
gcc: ChangeLog 
gcc/config/ia64: ia64.md 

Log message:
PR target/21556
* config/ia64/ia64.md (load_dtpmod, load_ltoff_dtpmod, load_dtprel,
load_dtprel64, load_dtprel22, load_dtprel_gd, load_ltoff_dtprel,
add_dtprel, add_dtprel14, add_dtprel22, load_tprel, load_tprel64,
load_tprel22, load_tprel_ie, load_ltoff_tprel, add_tprel, add_tprel14,
add_tprel22): Remove mode from symbolic operand.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.247&r2=2.7592.2.248
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.146.8.3&r2=1.146.8.4



-- 


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

[Bug target/21556] [4.0/4.1 Regression] TLS failures on 4.0 branch

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-05-16 18:26 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/21610] New: ICE in make_decl_rtl

[jakub at gcc dot gnu dot org]

struct S { char s; };
struct T { struct S t; };

struct S *const p = &((struct T * const) (0x4000))->t;

void
foo (void)
{
  p->s = 0;
}

ICEs at -O2 e.g. on {x86_64,i386}-linux on gcc-4_0-branch.  On HEAD it seems to
work by luck.

The problem seems to be tree sharing between p's initializer and foo's body.
The gimplifier destroys the tree, on HEAD then manages to fix it up again
by further optimizations.

-- 
   Summary: ICE in make_decl_rtl
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
19:02 ---
Subject: Bug 20504

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-16 19:01:52

Modified files:
libjava: ChangeLog 
libjava/gnu/regexp: RE.java 

Log message:
2005-05-16  Ziga Mahkovec  <[EMAIL PROTECTED]>

PR libgcj/20504
gnu/regexp/RE.java: Add support for quoting constructs.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3614&r2=1.3615
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/regexp/RE.java.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
19:03 ---
Subject: Bug 20504

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-16 19:03:02

Modified files:
libjava: ChangeLog 
libjava/gnu/regexp: RE.java 

Log message:
2005-05-16  Ziga Mahkovec  <[EMAIL PROTECTED]>

PR libgcj/20504
gnu/regexp/RE.java: Add support for quoting constructs.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.66&r2=1.3391.2.67
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/regexp/RE.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3&r2=1.3.2.1



-- 


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

[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-16 
19:06 ---
I checked this in everywhere.
Thanks for taking the time to write the test cases, that is excellent.


-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
19:15 ---
Hmm, shouldn't we unshare the tree when copy the value of p in? (oh that is 
what your patch does).
I wonder if we can just get rid of 
decl_constant_value_for_broken_optimization/decl_constant_value.

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||05/msg01566.html
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code, patch
   Last reconfirmed|-00-00 00:00:00 |2005-05-16 19:15:05
   date||
Summary|ICE in make_decl_rtl|[4.0/4.1 Regression] ICE in
   ||make_decl_rtl
   Target Milestone|--- |4.0.1


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

[Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
19:17 ---
Oh, I think the reason why the mainline does not create a new tree is because 
we don't gimple twice.

-- 


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

[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs

[ziga dot mahkovec at klika dot si]

--- Additional Comments From ziga dot mahkovec at klika dot si  2005-05-16 
19:18 ---
> I checked this in everywhere.

I was about to go through the procedure myself, but thanks anyway.
There was a typo in my initial ChangeLog entry though:

@@ -1,4 +1,4 @@
 2005-03-17  Ziga Mahkovec  <[EMAIL PROTECTED]>

PR libgcj/20504
-   gnu/regexp/RE.java: Add support for quoting constructs.
+   * gnu/regexp/RE.java: Add support for quoting constructs.

-- 


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

[Bug c++/21510] Possible bug

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-16 19:19 ---
Subject: Re:  Possible bug

"sven at clio dot in-berlin dot de" <[EMAIL PROTECTED]> writes:

| (In reply to comment #7) 
| > > Is there a way to distinguish between unions (which are not usable as 
base  
| > > classes) and classes? If not, the standard is incomplete. 
| >  
| > You should know that 10 years ago people didn't even imagine the kind of 
| > template usages that you are assuming as obvious. Indeed, everyone wants 
| > to tell unions from classes now and you bet, it will be possible sometime 
| > in the future, likely not using SFINAE at all. 
|  
| I know and accept this. SFINAE is a possible dangerous feature, anyway. It 
may 
| be better if the ISO standard declares something like the following 
| (incomplete, feel free to propose it to the standard comitee): 
|  
| The pragma statements 
|  
| _Pragme(set, "sfinae", on)   // enables SFINAE 
| _Pragma(set, "sfinae", off)  // disables SFINAE 
| _Pragma(reset, "sfinae") // sets SFINAE to the previous state 

Over my dead body. :-)

-- Gaby


-- 


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

[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-05-16 19:45 
---
The testcase pr19155.f fails on AIX.  I am confused if this is suppose to work
after the patch or not.  Either the testcase should be XFAILed or something else
is wrong with the patch.

-- 


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

[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-05-05 14:55:48 |2005-05-16 19:46:27
   date||


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

[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-05-16 19:48 
---
I don't see a blame for this regression, so here goes.
Passed with LAST_UPDATED "Wed May 11 04:48:16 UTC 2005" on cris-elf and
mmix-knuth-mmixware, failed with "Wed May 11 12:21:26 UTC 2005" and since.

-- 
   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug tree-optimization/20605] [4.1 Regression] gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
19:53 ---
Or it might be the testcase which is matching it wrong, someone already asked 
about this testcase 
before on IRC (IIRC) and the regex was just matching wrongly.

-- 


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

[Bug target/21050] [4.1 Regression] vect-none.c ICE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
19:54 ---
Again this is a latent target bug, Devang's patch just exposed the problem.

-- 


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

[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-05-16 
19:57 ---
2005-05-11  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/19807
PR tree-optimization/19639
* fold-const.c (try_move_mult_to_index): Handle INTEGER_CST
and generic summands for char* as s * delta, too, folding &a[i]
CODE x to &a[i CODE x/s].  Use tree_int_cst_equal
for comparison of steps.  Convert types for index addition.
(fold_binary): Adjust the callers to always dispatch to
try_move_mult_to_index.
* tree-ssa-propagate.c (set_rhs): Avoid setting rhs to
expr with non-gimple ARRAY_REF offset.


It exposed a latent bug in conjunction with


2005-05-10  Diego Novillo  <[EMAIL PROTECTED]>

* tree-optimize.c (init_tree_optimization_passes): Re-organize
optimization passes to do an initial batch of scalar cleanups.


which I had not in during testing.

-- 


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

[Bug ada/21611] New: ACATS Failures After Successfully Built using Cygwin 3.3.3

[anh_vn_vo at yahoo dot com]

Successfully built Ada compiler. When performing acats test, the test summary 
shown below indicates the failures.

make: Entering directory `/cygdrive/d/Build-Ada/gcc'
test -d testsuite/ada/acats || mkdir -p testsuite/ada/acats
testdir=`cd ../../gcc-4.0-20050430/gcc/testsuite/ada/acats; ${PWDCMD-pwd}`; \
export testdir; cd testsuite/ada/acats; ${testdir}/run_acats 
=== acats configuration ===
target gcc is /cygdrive/d/Build-Ada/gcc/xgcc -B/cygdrive/d/Build-Ada/gcc/
Reading specs from /cygdrive/d/Build-Ada/gcc/specs Target: i686-pc-cygwin 
Configured with: ../gcc-4.0-20050430/configure --enable-languages=ada --enable-
threads=gnat Thread model: gnat gcc version 4.0.1 20050430 (prerelease)
host=i686-pc-cygwin
target=i686-pc-cygwin
gnatmake is /cygdrive/d/Build-Ada/gcc/gnatmake

=== acats support ===
Generating support files... done.
Compiling support files... done.

=== acats tests ===
Running chapter a ...
Running chapter c2 ...
FAIL:   c23003b
FAIL:   c23003g
FAIL:   c23003i
Running chapter c3 ...
Running chapter c4 ...
Running chapter c5 ...
Running chapter c6 ...
FAIL:   c62003a
FAIL:   c62003b
FAIL:   c64103e
FAIL:   c64103f
FAIL:   c64104h
FAIL:   c64104j
FAIL:   c64104k
FAIL:   c64104l
FAIL:   c64104n
Running chapter c7 ...
Running chapter c8 ...
Running chapter c9 ...
FAIL:   c96005d
Running chapter ca ...
Running chapter cb ...
FAIL:   cb3004a
FAIL:   cb4001a
Running chapter cc ...
FAIL:   cc3017c
/cygdrive/d/gcc-4.0-20050430/gcc/testsuite/ada/acats/run_all.sh: cannot 
create /cygdrive/d/Build-Ada/gcc/testsuite/ada/acats/acats.log: error 16
make: *** [check-gnat] Error 2
make: Leaving directory `/cygdrive/d/Build-Ada/gcc'

-- 
   Summary: ACATS Failures After Successfully Built using Cygwin
3.3.3
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anh_vn_vo at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: PC Running Cygwin under XP


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

[Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-16 
20:01 ---
Subject: Re:  [4.0/4.1 Regression] ICE in
 make_decl_rtl

On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:

> Hmm, shouldn't we unshare the tree when copy the value of p in? (oh that is 
> what your patch does).
> I wonder if we can just get rid of 
> decl_constant_value_for_broken_optimization/decl_constant_value.

If you get rid of decl_constant_value_for_broken_optimization then I 
suspect you'll lose some optimizations because fold doesn't operate on SSA 
so some constant values won't be available to fold, only to later 
optimizations.  But you'll get rid of the only references to "optimize" in 
the C front end other than those defining built-in macros, and the 
front-end shouldn't care about "optimize" in principle, and you'll 
probably get rid of some XFAILs in c9?-const-expr-?.c in the process.



-- 


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

[Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
20:03 ---
(In reply to comment #3)
> If you get rid of decl_constant_value_for_broken_optimization then I 
> suspect you'll lose some optimizations because fold doesn't operate on SSA 
> so some constant values won't be available to fold, only to later 
> optimizations.  But you'll get rid of the only references to "optimize" in 
> the C front end other than those defining built-in macros, and the 
> front-end shouldn't care about "optimize" in principle, and you'll 
> probably get rid of some XFAILs in c9?-const-expr-?.c in the process.

Why do you believe fold does not operate on SSA?

-- 


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

[Bug tree-optimization/20605] [4.1 Regression] gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 fails

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-16 
20:05 ---
Subject: Re:  [4.1 Regression] gcc.dg/tree-ssa/loop-4.c
 scan-tree-dump-times iter 0 fails

On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:

> Or it might be the testcase which is matching it wrong, someone already asked 
> about this testcase 
> before on IRC (IIRC) and the regex was just matching wrongly.

No, that's bug 21341 (if indeed the problem was the regex, the submitter 
of the patch which changed the regex didn't mention the bug and its prior 
change from PASS to FAIL).  There are multiple test assertions within the 
same test file, and when any one changes from PASS to FAIL that is in 
principle, and in practice in this case, a separate bug.

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01057.html



-- 


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

[Bug libgcj/21606] java.net.URI fails to decode lowercase hex codes

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-16 
20:10 ---
I'm testing a patch.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-16 20:10:50
   date||


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

[Bug target/21050] [4.1 Regression] vect-none.c ICE

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-16 
20:11 ---
Subject: Re:  [4.1 Regression] vect-none.c ICE

On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:

> Again this is a latent target bug, Devang's patch just exposed the problem.

We don't make a distinction between intrinsically buggy patches and those 
exposing problems elsewhere if the regression appears with a given patch.  
This is explicit in develop.html but was the case even before that was 
established, and has been discussed before.



-- 


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

[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-16 
20:19 ---
Testcase pr19155.f does not fail on i386-linux, i686-freebsd and sparc-solaris.
With the patch committed, it is supposed to work. Can you investigate further
(compile the testcase manually and see why it fails)? I don't have access to a
AIX machine.

-- 


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

[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-16 20:27 
---
sixtrack and the testcase smsbug.f still fail on powerpc64-linux when compiled
with mainline GCC with the options "-m64 -O2 -fmodulo-sched".  The other
failures with those options mentioned in comment #4 have gone away.

-- 


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

[Bug libgcj/21606] java.net.URI fails to decode lowercase hex codes

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
20:27 ---
Subject: Bug 21606

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-16 20:27:48

Modified files:
libjava: ChangeLog 
libjava/java/net: URI.java 

Log message:
PR libgcj/21606:
* java/net/URI.java (unquote): Handle lower-case letters as well.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3615&r2=1.3616
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/net/URI.java.diff?cvsroot=gcc&r1=1.10&r2=1.11



-- 


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

[Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-16 
20:28 ---
Subject: Re:  [4.0/4.1 Regression] ICE in
 make_decl_rtl

On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:

> 
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
> 20:03 ---
> (In reply to comment #3)
> > If you get rid of decl_constant_value_for_broken_optimization then I 
> > suspect you'll lose some optimizations because fold doesn't operate on SSA 
> > so some constant values won't be available to fold, only to later 
> > optimizations.  But you'll get rid of the only references to "optimize" in 
> > the C front end other than those defining built-in macros, and the 
> > front-end shouldn't care about "optimize" in principle, and you'll 
> > probably get rid of some XFAILs in c9?-const-expr-?.c in the process.
> 
> Why do you believe fold does not operate on SSA?

Fold has optimizations working on large complicated trees of expressions, 
looking at their subexpressions and subsubexpressions; such trees are only 
available during parsing, before conversion to GIMPLE form.  If the 
constants aren't available in these non-GIMPLE trees then you lose the 
optimizations.  The folding called from the SSA optimizers can only fold 
smaller fragments of trees.  Everything fold does which looks at 
subexpressions and subsubexpressions of non-GIMPLE trees can in principle 
be done on GIMPLE but I don't think there's evidence that every such fold 
optimization is implemented for GIMPLE.

Here is a trivial example where the transformation ~A + 1 to -A is only 
done by the RTL optimizers in function g but is done by fold for function 
f.

int f(int a) { return ~a + 1; }
int g(int a) { int b = 1; return ~a + b; }



-- 


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

[Bug c++/21603] C++ front-end accepts "new" with VLAs

[jason at redhat dot com]

--- Additional Comments From jason at redhat dot com  2005-05-16 20:28 
---
Subject: Re:  New: C++ front-end accepts "new" with VLAs

On 16 May 2005 02:16:51 -, "mmitchel at gcc dot gnu dot org" <[EMAIL 
PROTECTED]> wrote:

> Steve Adamczyk has indicated that he feels that permitting dynamic allocation 
> of
> VLAs is a mistake, in that, for example, you can't easily use the pointer
> outside the scope of the containing function, unless you somehow also 
> pass/save
> the bounds.

Makes sense to me.

Jason


-- 


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

Re: [Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[Andrew Pinski]

On May 16, 2005, at 4:28 PM, joseph at codesourcery dot com wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org  
2005-05-16 20:03 ---
(In reply to comment #3)
If you get rid of decl_constant_value_for_broken_optimization then I
suspect you'll lose some optimizations because fold doesn't operate 
on SSA
so some constant values won't be available to fold, only to later
optimizations.  But you'll get rid of the only references to 
"optimize" in
the C front end other than those defining built-in macros, and the
front-end shouldn't care about "optimize" in principle, and you'll
probably get rid of some XFAILs in c9?-const-expr-?.c in the process.
Why do you believe fold does not operate on SSA?
Fold has optimizations working on large complicated trees of 
expressions,
looking at their subexpressions and subsubexpressions; such trees are 
only
available during parsing, before conversion to GIMPLE form.  If the
constants aren't available in these non-GIMPLE trees then you lose the
optimizations.  The folding called from the SSA optimizers can only 
fold
smaller fragments of trees.  Everything fold does which looks at
subexpressions and subsubexpressions of non-GIMPLE trees can in 
principle
be done on GIMPLE but I don't think there's evidence that every such 
fold
optimization is implemented for GIMPLE.
Yes that is what the tree combiner would do but since I have not have 
time
to work it, we are missing more and more optimizations because not 
having
it.

-- Pinski

[Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2005-05-16 
20:34 ---
Subject: Re:  [4.0/4.1 Regression] ICE in make_decl_rtl


On May 16, 2005, at 4:28 PM, joseph at codesourcery dot com wrote:
>> --- Additional Comments From pinskia at gcc dot gnu dot org  
>> 2005-05-16 20:03 ---
>> (In reply to comment #3)
>>> If you get rid of decl_constant_value_for_broken_optimization then I
>>> suspect you'll lose some optimizations because fold doesn't operate 
>>> on SSA
>>> so some constant values won't be available to fold, only to later
>>> optimizations.  But you'll get rid of the only references to 
>>> "optimize" in
>>> the C front end other than those defining built-in macros, and the
>>> front-end shouldn't care about "optimize" in principle, and you'll
>>> probably get rid of some XFAILs in c9?-const-expr-?.c in the process.
>>
>> Why do you believe fold does not operate on SSA?
>
> Fold has optimizations working on large complicated trees of 
> expressions,
> looking at their subexpressions and subsubexpressions; such trees are 
> only
> available during parsing, before conversion to GIMPLE form.  If the
> constants aren't available in these non-GIMPLE trees then you lose the
> optimizations.  The folding called from the SSA optimizers can only 
> fold
> smaller fragments of trees.  Everything fold does which looks at
> subexpressions and subsubexpressions of non-GIMPLE trees can in 
> principle
> be done on GIMPLE but I don't think there's evidence that every such 
> fold
> optimization is implemented for GIMPLE.

Yes that is what the tree combiner would do but since I have not have 
time
to work it, we are missing more and more optimizations because not 
having
it.

-- Pinski



-- 


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

[Bug libgcj/21606] java.net.URI fails to decode lowercase hex codes

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
20:35 ---
Subject: Bug 21606

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-16 20:35:23

Modified files:
libjava: ChangeLog 
libjava/java/net: URI.java 

Log message:
PR libgcj/21606:
* java/net/URI.java (unquote): Handle lower-case letters as well.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.67&r2=1.3391.2.68
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/net/URI.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9&r2=1.9.6.1



-- 


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

[Bug libgcj/21606] java.net.URI fails to decode lowercase hex codes

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-16 
20:39 ---
I've checked in the fix.
Thanks for the simple test case.


-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21155] [4.1 Regression] ICE in ssa tree check compiling crafty with -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-16 20:41 
---
The failure still exists with mainline GCC built last night:

elm3b145% /opt/gcc-nightly/mline-20050516/bin/gcc -O2 -ftree-vectorize -maltivec
-m64 crafty_bug.c
crafty_bug.c: In function ‘main’:
crafty_bug.c:31: internal compiler error: tree check: expected ssa_name, have
var_decl in is_old_name, at tree-into-ssa.c:467

SPEC CPU2000 tests gcc, crafty, and mesa all get this ICE.  Tests gap, facerec,
and apsi get segfaults in the compiler and resist attempts at mininizing test
cases.

-- 
   What|Removed |Added

 CC||dorit at gcc dot gnu dot org


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

[Bug c++/21612] New: Strange symbols printed all over the error messages

[yuri at tsoft dot com]

See below(âEâ), it's trashed quote or something of that kind.

Yuri

--begin code--
E e;
--end code--
--begin error--
x.C:3: error: âEâ does not name a type
--end error--

-- 
   Summary: Strange symbols printed all over the error messages
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21612] Strange symbols printed all over the error messages

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
20:52 ---
It is UTF-8 character, read the changes page.  Basically you LANG/LN_* 
environment variable says your 
terminal supports UTF-8 but in reality it does not.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/21612] Strange symbols printed all over the error messages

[yuri at Magma-DA dot COM]

--- Additional Comments From yuri at Magma-DA dot COM  2005-05-16 21:05 
---
Subject: Re:  Strange symbols printed all over the error messages

Agree, I must have wrong setting.

But how does compiler with US English languege benefit of UTF anyways?

Isn't it better practice to not step on such things if they are not 
important for gcc ?
For most people this is likely to cause some doubts in gcc once they see 
this even though this is their setup -- better to avoid them I think.

Yuri


pinskia at gcc dot gnu dot org wrote:

>--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
>20:52 ---
>It is UTF-8 character, read the changes page.  Basically you LANG/LN_* 
>environment variable says your 
>terminal supports UTF-8 but in reality it does not.
>
>  
>



-- 


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

[Bug c++/21612] Strange symbols printed all over the error messages

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2005-05-16 
21:07 ---
Subject: Re:  Strange symbols printed all over the error messages


On May 16, 2005, at 5:04 PM, Yuri wrote:

> Agree, I must have wrong setting.
>
> But how does compiler with US English languege benefit of UTF anyways?

I would read the link off of the changes page because it explains why 
this really
done.

Thanks,
Andrew Pinski



-- 


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

[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
21:27 ---
I have a patch for this.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/21562] [4.0/4.1 Regression] Quiet bad codegen (unrolling + tail call interaction)

[dalej at gcc dot gnu dot org]

--- Additional Comments From dalej at gcc dot gnu dot org  2005-05-16 21:44 
---
OK, what happens is that tail call creates a block 0 with multiple 
predecessors, and the
out-of-ssa pass mangles that into this form:

  # BLOCK 0
  # PRED: 9 [14.9%]  (true,exec) 1 [29.0%]  (true,exec)
:;
  posD.1132 = aposD.1138;
  # SUCC: 12 [100.0%]  (fallthru)

  # BLOCK 12
  # PRED: 0 [100.0%]  (fallthru) ENTRY [100.0%]  (fallthru,exec)
:;
  *((intD.0 *) ((unsigned intD.3) posD.1132 * 4) + mrD.1133) = 1;

where ENTRY no longer falls into block 0, but is expected to jump to block 12.  
Expand has no
idea such a thing is possible and falls through anyway.  While it's not obvious 
in 4.0 branch, the
addition of a verify_flow_info failure in mainline makes it apparent this is 
not supposed to happen.

One way to fix this is change tailcall so it splits block 0 instead of creating 
multiple predecessors
for it.  I'll go do that unless somebody has a better idea.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dalej at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug target/3506] weird behaviour when incrementing volatile ints

[mrd at alkemio dot org]

--- Additional Comments From mrd at alkemio dot org  2005-05-16 22:34 
---
(In reply to comment #5)
> Mark as invalid.

Why?

-- 


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

[Bug AWT/20790] libjawt.so must be renamed

[fitzsim at redhat dot com]

--- Additional Comments From fitzsim at redhat dot com  2005-05-16 22:45 
---
Renamed libgcjawt.so on mainline.  Closing.


-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21562] [4.0/4.1 Regression] Quiet bad codegen (unrolling + tail call interaction)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
22:54 ---
(In reply to comment #4)
> where ENTRY no longer falls into block 0, but is expected to jump to block 
> 12.  Expand has no
> idea such a thing is possible and falls through anyway.  While it's not 
> obvious in 4.0 branch, the
> addition of a verify_flow_info failure in mainline makes it apparent this is 
> not supposed to happen.
If you turn on checking it will fail on the 4.0 branch.

-- Pinski

-- 


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

[Bug target/3506] weird behaviour when incrementing volatile ints

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-16 
22:57 ---
(In reply to comment #7)
> (In reply to comment #5)
> > Mark as invalid.
> 
> Why?

Did you read comment #1.

-- 


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

[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-16 
23:14 ---
Subject: Bug 21399

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-16 23:14:02

Modified files:
gcc: ChangeLog tree-eh.c tree-flow.h tree-ssa-ccp.c 
 tree-ssa-dom.c tree-ssa-pre.c 
 tree-ssa-propagate.c 

Log message:
PR tree-opt/21399
* tree-eh.c (maybe_clean_or_replace_eh_stmt): Rename from
maybe_clean_eh_stmt; take old stmt parameter.  Update EH
region data structure to match replacement.
* tree-flow.h: Update to match.
* tree-ssa-ccp.c (execute_fold_all_builtins): Likewise.
* tree-ssa-dom.c (optimize_stmt): Likewise.
* tree-ssa-pre.c (eliminate): Likewise.
* tree-ssa-propagate.c (substitute_and_fold): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8806&r2=2.8807
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-eh.c.diff?cvsroot=gcc&r1=2.38&r2=2.39
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.104&r2=2.105
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gcc&r1=2.70&r2=2.71
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gcc&r1=2.110&r2=2.111
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.88&r2=2.89
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-propagate.c.diff?cvsroot=gcc&r1=2.19&r2=2.20



-- 


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

[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-05-16 23:16 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/3506] weird behaviour when incrementing volatile ints

[mrd at alkemio dot org]

--- Additional Comments From mrd at alkemio dot org  2005-05-17 00:33 
---
(In reply to comment #8)
> Did you read comment #1.

Yes, but it's not clear.

> GCC doesn't know what constitutes a reference to a volatile memory

Is this to say the GCC developers believe the C language's definition of
"volatile" is ambiguous, or that there are situations where "incl x" is
operationally distinct from "movl x, %eax; incl %eax; movl %eax, x" when x is
volatile?

-- 


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

[Bug libgcj/21140] [4.0 only] Charset.encode and Charset.decode broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 
01:46 ---
Subject: Bug 21140

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-17 01:46:06

Modified files:
libjava: ChangeLog 
libjava/java/nio/charset: Charset.java 

Log message:
PR libgcj/21140:
* java/nio/charset/Charset.java (encode, decode): Don't cache.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.69&r2=1.3391.2.70
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/charset/Charset.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9&r2=1.9.2.1



-- 


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

[Bug libgcj/21140] [4.0 only] Charset.encode and Charset.decode broken

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-17 
01:50 ---
Fix checked in.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/21613] New: -fpic only: internal compiler error: in extract_insn, at recog.c:2083 (20010107-1.c:6)

[flash at pobox dot com]

The following gives "internal compiler error: in extract_insn, at 
recog.c:2083", only with -fpic: 

arm-softfloat-linux-gnu-g++ -fpic   ../c/noerror/GPL/20010107-1.c

20010107-1.c is a C Torture file, containing only the following:

unsigned long x[4];
void foo(void)
{
  ((void (*)())(x+2))();
}


This sounds similar to 19960 (darwin/m6811-elf) and 19770 (hppa64/hppa64).
I'll attach the preprocessed file (though it's hardly necessary, since there 
are no #includes), and the -v 
-savetemps output.

Here's the full error message:

../c/noerror/GPL/20010107-1.c: In function `void foo()':
../c/noerror/GPL/20010107-1.c:6: error: unrecognizable insn:
(call_insn 14 13 16 0 (parallel [
(call (mem:SI (plus:SI (reg/f:SI 68)
(const_int 8 [0x8])) [0 S4 A32])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) -1 (nil)
(expr_list:REG_DEAD (reg/f:SI 68)
(expr_list:REG_UNUSED (reg:SI 14 lr)
(nil)))
(nil))
../c/noerror/GPL/20010107-1.c:6: internal compiler error: in extract_insn, at 
recog.c:2083


---
Flash Sheridan
[EMAIL PROTECTED]
Quality Lead for Compilers and Debuggers
PalmSource, Inc. Tools Quality Management

-- 
   Summary: -fpic only: internal compiler error: in extract_insn, at
recog.c:2083 (20010107-1.c:6)
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: flash at pobox dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: arm-softfloat-linux-gnu


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

[Bug target/19770] gcc.c-torture/compile/20050113-1.c: ICE: in extract_insn, at recog.c:2083

[flash at pobox dot com]

--- Additional Comments From flash at pobox dot com  2005-05-17 03:26 
---
See also 19960 (darwin/m6811-elf) and 21613 (i686-linux/arm-linux).

-- 
   What|Removed |Added

 CC||flash at pobox dot com


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

[Bug target/19960] internal compiler error: in extract_insn, at recog.c:2175

[flash at pobox dot com]

--- Additional Comments From flash at pobox dot com  2005-05-17 03:27 
---
See also 19770 (hppa64/hppa64) and 21613 (i686-linux/arm-linux).

-- 
   What|Removed |Added

 CC||flash at pobox dot com


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

[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot

[bernie at develer dot com]

--- Additional Comments From bernie at develer dot com  2005-05-17 05:40 
---
I'm still seeing the artsd miscompilation with
gcc 4.0.0 20050512 (Red Hat 4.0.0-5), which contains everything
from gcc-4_0-branch upto 13-05-2005 (circa).

This is from an arts *client*:

Starting program: /home/bernie/src/gfactory/src/gfactory
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x73d000
[Thread debugging using libthread_db enabled]
[New Thread -1209042464 (LWP 20182)]
unix_connect: can't connect to server
(unix:/tmp/mcop-root/beetle_trilan-0cad-4289417b)
bernie: here9

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209042464 (LWP 20182)]
0x006359b7 in __gnu_cxx::__pool::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
(gdb) bt
#0  0x006359b7 in __gnu_cxx::__pool::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
#1  0x00913fef in __gnu_cxx::__mt_alloc >::deallocate
(this=0xbfc1fd38, __p=0x8509c68, __n=1)
at
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ext/mt_allocator.h:746
#2  0x00914029 in std::_Vector_base
>::_M_deallocate (this=0xbfc1fd38,
__p=0x8509c68, __n=1)
at
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:123
#3  0x00914066 in ~_Vector_base (this=0xbfc1fd38)
at
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:109
#4  0x009140cf in ~vector (this=0xbfc1fd38)
at
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:273
#5  0x00914102 in ~ObjectReference (this=0xbfc1fd2c) at
/usr/local/src/kde/arts/mcop/reference.h:48
#6  0x009069ad in Arts::SoundServer_base::_fromString ([EMAIL PROTECTED]) at
soundserver.cc:1452
#7  0x00e1f0aa in arts_backend_init () from 
/usr/local/kde/lib/libartscbackend.so.0
#8  0xbfc1fd90 in ?? ()
#9  0x00e258cc in typeinfo name for Sender () from
/usr/local/kde/lib/libartscbackend.so.0
#10 0x0017 in ?? ()
Previous frame inner to this frame (corrupt stack?)


-- 


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

[Bug c++/21614] New: invokation of undefined class'es method is ignored

[yuri at tsoft dot com]

gcc 4.0.0 generates code that has line (**) ignored (nothing is invoked in it's
place).

I am not sure in what kind of relationship does this code stand with C++ 
standard.

But although structure X::Z is undefined, technically method Y::r can be invoked
safely since X::Z definition isn't required for this.

This code used to compile and work fine -- line (**) was invoked.

Yuri


--begin code--
class X;
class Y;

class X {
public:
  struct Z;
  typedef void (Z::* R) (unsigned int ss);

  void   rr (unsigned int ss);

  Y*d;
};

class Y {
public:
  X::R  r;
  X::Z* d;
  Y*n;
  Y(X::R _r, X::Z* _d) : r(_r), d(_d) { }
};

extern void ck();

void  X::rr (unsigned int ss) {
  for (Y* l = d;  l;  l = l->n) {
ck();
((l->d)->*(l->r))(ss); // (**) ignored line
ck();
  }
}
--end code--

-- 
   Summary: invokation of undefined class'es method is ignored
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 
06:31 ---
Subject: Bug 15080

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-17 06:31:51

Modified files:
gcc/fortran: ChangeLog 
gcc/testsuite  : ChangeLog 
gcc/fortran: trans-stmt.c 
gcc/testsuite/gfortran.fortran-torture/execute: forall_3.f90 
Added files:
gcc/testsuite/gfortran.fortran-torture/execute: where_7.f90 
where_8.f90 

Log message:
PR fortran/15080
* trans-stmt.c (generate_loop_for_temp_to_lhs): Remove SIZE and COUNT2
arguments.  If LSS is gfc_ss_terminator, increment COUNT1 by 1, instead
of incrementing COUNT2 and using COUNT1+COUNT2 increment COUNT1 and use
just that as index.
(generate_loop_for_rhs_to_temp): Likewise.
(compute_overall_iter_number): Add INNER_SIZE_BODY argument.
It non-NULL, add it to body.
(allocate_temp_for_forall_nest_1): New function, split from
allocate_temp_for_forall_nest.
(allocate_temp_for_forall_nest): Add INNER_SIZE_BODY argument,
propagate it down to compute_overall_iter_number.  Use
allocate_temp_for_forall_nest_1.
(gfc_trans_assign_need_temp): Remove COUNT2.  Call
compute_inner_temp_size into a new stmtblock_t.  Adjust calls to
allocate_temp_for_forall_nest, generate_loop_for_rhs_to_temp
and generate_loop_for_temp_to_lhs.
(gfc_trans_pointer_assign_need_temp): Adjust calls to
allocate_temp_for_forall_nest.
(gfc_evaluate_where_mask): Call compute_inner_temp_size into a new
stmtblock_t.  Call compute_overall_iter_number just once, then
allocate_temp_for_forall_nest_1 twice with the same size.
Initialize mask indexes if nested_forall_info != NULL.
(gfc_trans_where_2): Initialize mask indexes before calling
gfc_trans_nested_forall_loop.

* gfortran.fortran-torture/execute/forall_3.f90: Remove comment
about the test failing.
* gfortran.fortran-torture/execute/where_7.f90: New test.
* gfortran.fortran-torture/execute/where_8.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.425&r2=1.426
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5478&r2=1.5479
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&r1=1.30&r2=1.31
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_7.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_8.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/forall_3.f90.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug tree-optimization/21610] [4.0/4.1 Regression] ICE in make_decl_rtl

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 
06:45 ---
Subject: Bug 21610

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-17 06:45:49

Modified files:
gcc: ChangeLog c-typeck.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050516-1.c 

Log message:
PR tree-optimization/21610
* c-typeck.c (decl_constant_value_for_broken_optimization): If not
returning DECL, call unshare_expr.

* gcc.c-torture/compile/20050516-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8811&r2=2.8812
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.441&r2=1.442
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5479&r2=1.5480
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050516-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/21492] [4.0/4.1 Regression] ICE in try_crossjump_to_edge

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 
06:48 ---
Subject: Bug 21492

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-17 06:48:19

Modified files:
gcc: ChangeLog cfgcleanup.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/opt: crossjump1.C 

Log message:
PR middle-end/21492
* cfgcleanup.c (try_crossjump_to_edge): update_forwarder_flag for
src2 if src2 has been split.

* g++.dg/opt/crossjump1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8812&r2=2.8813
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cfgcleanup.c.diff?cvsroot=gcc&r1=1.144&r2=1.145
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5480&r2=1.5481
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/crossjump1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/21454] [4.0/4.1 Regression] const array doesn't live in the rodata section in C++

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 
06:51 ---
Subject: Bug 21454

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-17 06:51:48

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog 
gcc/cp : decl.c 
Added files:
gcc/testsuite/g++.dg/opt: const4.C 

Log message:
PR c++/21454
* decl.c (maybe_deduce_size_from_array_init): Call
cp_apply_type_quals_to_decl after completing array type.

* g++.dg/opt/const4.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5481&r2=1.5482
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4743&r2=1.4744
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1393&r2=1.1394
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/const4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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