[Bug AWT/21604] New: strange refresh behavior when moving mouse
I'm using the applet here: http://www.chessgames.com/perl/chessgame?gid=1069669 with gcjappletviewer. (As of this writing I needed a patch to make this work at all, see the classpath-patches list.) When the applet window first comes up, if I move the mouse from the applet window into another unrelated window, the applet window will do a full refresh. If I move the mouse from the applet window to the desktop, nothing special happens. (The same thing happens when moving the mouse from a window into the applet, but again does not happen when moving from the desktop into the applet.) After I make a move in the applet, this refresh behavior stops. -- Summary: strange refresh behavior when moving mouse Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21604
[Bug target/19704] ICE for tail call of regparm 3 and dllimport
--- 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
--- 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 objects.
| | 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 stdio.h
|
| 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
--- 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
--- 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
-- 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
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 #3611;main#3595;:
testcase_not_executed.c:29: Warnung: wird niemals ausgef#63685;hrt
[EMAIL PROTECTED] test]$
[EMAIL PROTECTED] test]$ gcc -O2 -Wunreachable-code testcase_not_executed.c
testcase_not_executed.c: In Funktion #3611;main#3595;:
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:25: Warnung: wird niemals ausgef#63685;hrt
testcase_not_executed.c:29: Warnung: wird niemals ausgef#63685;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 stdlib.h
#include stdio.h
#include string.h
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
--- 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
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
--- 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=gccr1=1.116r2=1.117 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gccr1=1.662r2=1.663 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20270
[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols
--- 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=gccr1=1.116r2=1.117 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gccr1=1.662r2=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
--- 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=8899action=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
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 21 | 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 = width of type
[Bug target/19704] ICE for tail call of regparm 3 and dllimport
-- 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
-- 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'
-- 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?
--- 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
--- 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
--- 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 objects.
- 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 otherwises 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 stdio.h
|
| 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)
|
|char ca[4] = (b); // compiles without warning/error.
|((char *)ca)[1] =
[Bug c/21607] New: Optimizations convert 0 to -0 leading to difference in answers.
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.
--- 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=8901action=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.
--- 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=8902action=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.
--- 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
--- 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 retval = (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 D1580;
}
else
{
}
D.1583 = !b;
if (D.1583)
{
goto D1580;
}
else
{
}
iftmp.0 = 1;
goto D1581;
D1580:;
iftmp.0 = 0;
D1581:;
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.
--- 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
--- 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
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;
bb 0:
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
--- 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
--- 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.
--- 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
--- 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.
--- 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)
-- 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
--- 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
--- 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
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
--- 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
--- 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 objects.
|
| - 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 stdio.h
| |
| | 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
--- 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
--- 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
--- 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
--- 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=gccr1=2.8802r2=2.8803 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gccr1=1.152r2=1.153 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
[Bug libstdc++/21609] array_allocator vs rebind templated constructor
--- 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
--- 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=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.247r2=2.7592.2.248 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.146.8.3r2=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
--- 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
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
--- 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=gccr1=1.3614r2=1.3615 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/regexp/RE.java.diff?cvsroot=gccr1=1.3r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs
--- 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=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.66r2=1.3391.2.67 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/regexp/RE.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3r2=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
--- 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
--- 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
--- 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
--- 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
--- 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)
--- 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
-- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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)
--- 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
--- 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
--- 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=gccr1=1.3615r2=1.3616 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/net/URI.java.diff?cvsroot=gccr1=1.10r2=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
--- 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
--- 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
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
--- 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
--- 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=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.67r2=1.3391.2.68 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/net/URI.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9r2=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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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)
--- 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) L37:; posD.1132 = aposD.1138; # SUCC: 12 [100.0%] (fallthru) # BLOCK 12 # PRED: 0 [100.0%] (fallthru) ENTRY [100.0%] (fallthru,exec) L38:; *((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
--- 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
--- 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)
--- 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
--- 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
--- 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=gccr1=2.8806r2=2.8807 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-eh.c.diff?cvsroot=gccr1=2.38r2=2.39 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gccr1=2.104r2=2.105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gccr1=2.70r2=2.71 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gccr1=2.110r2=2.111 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gccr1=2.88r2=2.89 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-propagate.c.diff?cvsroot=gccr1=2.19r2=2.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- 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
--- 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
--- 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=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.69r2=1.3391.2.70 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/charset/Charset.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9r2=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
--- 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)
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
--- 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
--- 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
--- 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::__pooltrue::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x006359b7 in __gnu_cxx::__pooltrue::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x00913fef in __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::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_basestd::string, std::allocatorstd::string ::_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
