[Bug target/18847] ACATS cxa5012 SEGV on on x86_64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-16 07:22 --- Subject: Bug 18847 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-16 07:22:03 Modified files: gcc/ada: a-nudira.adb a-nuflra.adb ChangeLog Log message: 2005-04-16 Laurent GUERBY [EMAIL PROTECTED] PR ada/18847 * a-nudira.adb (Value): Check for valid string. * a-nuflra.adb (Value): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/a-nudira.adb.diff?cvsroot=gccr1=1.5r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/a-nuflra.adb.diff?cvsroot=gccr1=1.5r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gccr1=1.660r2=1.661 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18847
[Bug ada/21053] Warnings from init.c
--- Additional Comments From laurent at guerby dot net 2005-04-16 07:38
---
Could you try the obvious patch below?
It looks like the same problem as PR ada/17527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17527
which was fixed the same way a while ago.
I believe you can commit as obvious once tested.
There are other occurence of the same code for other target, but I don't have
access to them, may be Arnaud?
Index: init.c
===
RCS file: /cvs/gcc/gcc/gcc/ada/init.c,v
retrieving revision 1.47
diff -u -r1.47 init.c
--- init.c 10 Apr 2005 17:38:53 - 1.47
+++ init.c 16 Apr 2005 07:34:39 -
@@ -603,7 +603,7 @@
__gnat_error_handler (int sig, siginfo_t *siginfo, void *ucontext)
{
struct Exception_Data *exception;
- char *msg;
+ const char *msg;
switch (sig)
{
--
What|Removed |Added
CC||charlet at adacore dot com
Keywords||build, patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21053
[Bug c++/21042] Error when compiling jdk14
-- What|Removed |Added Component|target |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-16 10:37 --- Subject: Bug 20491 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-16 10:37:31 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.c Log message: PR middle-end/20491 * config/ia64/ia64.c (rtx_needs_barrier): Recurse instead of falling through from SUBREG case to REG. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8319r2=2.8320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gccr1=1.354r2=1.355 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug driver/21055] New: Option -Wl,-wrap when no input file
Why there is no 'input file error' when using -Wl,-wrap ? $ gcc -shared -o champion.so gcc: no input files $ gcc -shared -o champion.so -Wl,-wrap -Wl,toto $ ld -shared -o champion.so -wrap toto ld: no input files -- Summary: Option -Wl,-wrap when no input file Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: minor Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bitmap at pan dot homelinux dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs Configur GCC host triplet: Linux GCC target triplet: gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21055
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-16 10:43 --- Subject: Bug 20491 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-16 10:43:07 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.c Log message: PR middle-end/20491 * config/ia64/ia64.c (rtx_needs_barrier): Recurse instead of falling through from SUBREG case to REG. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.161r2=2.7592.2.162 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.347.2.2r2=1.347.2.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug c++/21056] New: Linker errors when deriving from std::iostream
The following simple program doesn't link:
- Derived.h -
#ifndef Derived_hh
#define Derived_hh
#include istream
#include ostream
class D : public std::iostream
{
public:
~D() ;
} ;
#endif
- Derived.cc -
#include Derived.hh
D::~D()
{
}
- main.cc -
#include Derived.hh
int
main()
{
D d ;
return 0 ;
}
- -
The compiler command was simply g++ main.cc Derived.cc.
Output was:
- compiler output -
/home/kanze/tmp/ccJrgTHi.o(.gnu.linkonce.t._ZN1DC1Ev+0x29): In function
`D::D()':
: undefined reference to `std::basic_iostreamchar, std::char_traitschar
::basic_iostream()'
/home/kanze/tmp/cctV9drU.o(.text+0x149): In function `D::~D()':
: undefined reference to `std::basic_iostreamchar, std::char_traitschar
::~basic_iostream()'
/home/kanze/tmp/cctV9drU.o(.text+0x1fa): In function `D::~D()':
: undefined reference to `std::basic_iostreamchar, std::char_traitschar
::~basic_iostream()'
/home/kanze/tmp/cctV9drU.o(.text+0x2ac): In function `D::~D()':
: undefined reference to `std::basic_iostreamchar, std::char_traitschar
::~basic_iostream()'
/home/kanze/tmp/cctV9drU.o(.gnu.linkonce.r._ZTC1D0_Sd+0xc): undefined reference
to `std::basic_iostreamchar, std::char_traitschar ::~basic_iostream()'
/home/kanze/tmp/cctV9drU.o(.gnu.linkonce.r._ZTC1D0_Sd+0x10): undefined reference
to `std::basic_iostreamchar, std::char_traitschar ::~basic_iostream()'
collect2: ld returned 1 exit status
- -
I'm not an expert in your template instantiation strategy, but
when I compile Derived.cc separately, then use nm on the object
file, I find unresolved externals for symbols like std::iostream::~iostream
(which shouldn't exist except as a typedef to a template instantiation,
I think). From what little I understand, I would have expected a
weak definition for the template instantiation (the missing function
in the messages above).
The relevant options I used when building the compiler were:
--enable-threads --enable-__cxa_atexit --disable-nls
(I don't think they have anything to do with the problem, but one
never knows.)
--
James Kanze
--
Summary: Linker errors when deriving from std::iostream
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: james dot kanze at free dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21056
[Bug c++/21056] Linker errors when deriving from std::iostream
--- Additional Comments From pcarlini at suse dot de 2005-04-16 11:53 --- Can you please try either a snapshot of 3.4.4 or 4.0? I'm pretty sure this is already fixed: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00308.html. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21056
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Additional Comments From bagnara at cs dot unipr dot it 2005-04-16 12:27 --- I can add the following: 1) the bug was not present in GCC 3.3.3 and is present since version 3.4.0, so I think it qualifies as a regression; 2) the bug is also present in GCC 4.0.0 20050226 (prerelease), which compiles the code even worse than done by GCC 3.4.3 (for whatever optimization level and -march option one gives). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c++/21057] New: iso C99 complex double: problems with g++
Hallo.
I want to use the ISO C99 complex datatypes in c++ because they are faster than
the template complex types from std++.
g++ fails to work with ISO C99 complex in the following way:
typedefs+built-in-functions(conj)+unary minus are not working well together.
cat test.cpp
#include /usr/include/complex.h
typedef complex double zcomplex;
int main()
{
zcomplex f=1+_Complex_I*1;
f=-_Complex_I;
f=conj(f);
return 0;
}
g++ -Wall test.cpp
test.cpp: In function `int main()':
test.cpp:9: error: wrong type argument to unary minus
test.cpp:11: error: wrong type argument to conjugation
g++ -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man
--enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib
--enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.4 (pre 3.3.5 20040809)
gcc compiles the c-version without problems.
g++-versions 3.3.4,3.4.3(mingw),3.1.x,... are broken.
--
Summary: iso C99 complex double: problems with g++
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hartmann at physik dot uni-kl dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21057
[Bug target/21042] Error when compiling jdk14
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16
13:06 ---
The following shows that this is a target issue:
{standard input}:105865: Error: suffix or operands invalid for `mov'
Also did you readh http://gcc.gnu.org/bugs.html as instructed anyways.
--
What|Removed |Added
Component|c++ |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug driver/21055] Option -Wl,-wrap when no input file
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 13:10 --- $ gcc -shared -o champion.so -Wl,-wrap -Wl,toto Because we add -lgcc -lc and others, so this is not a bug at all. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|Reading specs from |Reading specs from |/usr/lib/gcc/i486- |/usr/lib/gcc/i486- |linux/3.4.4/specs |linux/3.4.4/specsConfigur Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21055
[Bug c++/21056] Linker errors when deriving from std::iostream
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 13:12 --- Fixed but really this is binutils bug but oh well. -- What|Removed |Added Severity|critical|normal Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21056
[Bug c++/21057] iso C99 complex double: problems with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 13:15 --- I want to use the ISO C99 complex datatypes in c++ because they are faster than the template complex types from std++. Why do you say that? Well maybe before 4.0.0 it was slower but only slightly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21057
[Bug target/18847] [4.0 only] ACATS cxa5012 SEGV on on x86_64
-- What|Removed |Added Summary|ACATS cxa5012 SEGV on on|[4.0 only] ACATS cxa5012 |x86_64 |SEGV on on x86_64 Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18847
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 13:47 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01691.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug middle-end/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-16 14:07 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01830.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-16 15:15 --- It is apparently not possible to convince people that any optimizations in CSE can be removed, so working on this is pointless for me. See http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01498.html. -- What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug libgcj/11900] java.rmi.Naming does not parse rmi: URIs correctly
--- Additional Comments From gnu_andrew at member dot fsf dot org 2005-04-16 15:47 --- I'm attaching a patch which I've just committed to GNU Classpath CVS. This fixes this problem, using java.net.URI for interpretation as suggested. All methods also now follow a common scheme, via the use of two new private methods. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11900
[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-16
15:48 ---
The problem originates in find_reloads_subreg_address, which decides
to widen access to a memory reference. The instruction we have is:
(insn 129 127 130 10 (parallel [
(set (reg:SI 106)
(plus:SI (subreg:SI (reg:QI 104) 0)
(subreg:SI (reg:QI 105) 0)))
(clobber (reg:CC 33 %cc))
]) 143 {addsi3} (insn_list:REG_DEP_TRUE 128 (insn_list:REG_DEP_TRUE 127
(nil)))
(expr_list:REG_DEAD (reg:QI 104)
(expr_list:REG_DEAD (reg:QI 105)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)
and register 104 is equivalent to a memory slot:
(insn 127 128 129 10 (set (reg:QI 104)
(mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])) 53 {*movqi}
(insn_list:REG_DEP_TRUE 81 (insn_list:REG_DEP_TRUE 88 (insn_list:REG_DEP_TR
UE 95 (insn_list:REG_DEP_TRUE 102 (insn_list:REG_DEP_TRUE 109
(insn_list:REG_DEP_TRUE 116 (insn_list:REG_DEP_TRUE 123 (nil
(expr_list:REG_EQUIV (mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])
(nil)))
Now, reg 104 does not get a hard reg assigned. However, register 47 gets
assigned hard reg 0, which is not valid in a memory address.
Because register 104 is now equivalent to an invalid memory reference,
find_reloads_toplev calls find_reloads_subreg_address on the paradoxical
(subreg:SI (reg:QI 104)).
That routine thinks it can replace the subreg with an adjusted equivalent
memory reference (mem:SI (plus (reg 0) (const_int -3))).
It then calls find_reloads_address on that address. Now, this address
is invalid for *two* reasons: register 0 cannot be used as base register,
and negative displacements are invalid. find_reloads_address is unable
to cope with this combination, and returns with an address that is still
invalid.
[ If LEGITIMIZE_RELOAD_ADDRESS is active, it fixes the negative displacement
but keeps register 0. If I disable LEGITIMIZE_RELOAD_ADDRESS, the default
find_reloads_address behaviour will reload register 0, but keep the invalid
displacement. ]
As a workaround, I can add code to LEGITIMIZE_RELOAD_ADDRESS that fixes
both issues and results in a valid address, fixing the ICE. However, this
has two problems:
1. According to my understanding, L_R_A should never be required for
correctness, but only bring extra performance. Thus find_reloads_address
alone should also be able to fix the problem.
2. The whole business of widening access to a memory slot is questionable
in this case: if register 47 were to point to the start of a page of memory
preceded by unmapped address space, the widened access would crash. I had
thought that for this reason, only accesses to *stack slots* can be widened;
scan_paradoxical_subregs would make sure such stack slots are aligned
properly. However, in this case just some random memory access is widened.
As a final comment: both test cases in this PR are strictly speaking
invalid C or C++, because uninitialized variables are accessed. I was
unable to modify the test cases to valid C/C++. Does the original
unreduced source code also have uninitialized variables? There have
been some issues in the past where reload would handle uninitialized
pseudos correctly ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug libgcj/21058] New: libgcj can't find class
Given the following test program:
cut here ---
import java.awt.*;
import javax.imageio.*;
public class ShowJPEGReader
{
public static void main (String args[])
{
System.out.println (Toolkit.getDefaultToolkit ());
System.out.println (ImageIO.getImageReadersByFormatName(JPEG).next());
}
}
cut here ---
Running it results in:
$ gij ShowJPEGReader
[EMAIL PROTECTED]
Exception in thread main java.lang.NoClassDefFoundError: while resolving
class: javax.imageio.ImageIO
at java.lang.VMClassLoader.transformException(java.lang.Class,
java.lang.Throwable) (/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.Class.initializeClass()
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at ShowJPEGReader.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main()
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
Caused by: java.lang.ClassNotFoundException:
javax.imageio.ImageIO$ReaderMIMETypeFilter not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(java.lang.String)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
...5 more
But javax.imageio.ImageIO$ReaderMIMETypeFilter is here:
$ nm -D ~/FSF/i/lib/libgcj.so.6.0.0 | c++filt | grep ReaderMIMETypeFilter
00deb9e0 D javax::imageio::ImageIO$ReaderMIMETypeFilter::class$
008fcc50 T
javax::imageio::ImageIO$ReaderMIMETypeFilter::filter(java::lang::Object*)
008fcc10 T
javax::imageio::ImageIO$ReaderMIMETypeFilter::ImageIO$ReaderMIMETypeFilter(java::lang::String*)
00deba80 D vtable for javax::imageio::ImageIO$ReaderMIMETypeFilter
--
Summary: libgcj can't find class
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: aph at redhat dot com,gcc-bugs at gcc dot gnu dot
org,java-prs at gcc dot gnu dot org,tromey at redhat dot
com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21058
[Bug target/21042] Error when compiling jdk14
--- Additional Comments From samedii at gmail dot com 2005-04-16 16:09 --- Okay, thanks. Yes I did read the instructions for reporting bugs and I did my best with the parts that I understod. My jdk14 was not the absolute latest (it used the 6th patch instead of the 7th) and right now I'm trying to compile it again after downloading the latest port from ftp.freebsd.org. My server (which I'm compiling on) isn't that quick though so it may take some time before I know whether it works or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug target/21042] Error when compiling jdk14
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:11 --- Snce Sun's java code cannot be distributed, I am closing this as invalid. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug target/21042] Error when compiling jdk14
--- Additional Comments From samedii at gmail dot com 2005-04-16 16:15 --- What do I do then? Update to a later version of gcc? Report the bug to Sun? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-16 16:15 --- Much the same issue can arise with array references through pointer-to-aligned-type, and with arithmetic on such pointers, as does with array-of-aligned-type. However, having extra alignment on a DECL, as opposed to on its type, doesn't cause problems. The obvious options include: * Make a new type of larger size to match the alignment whenever e.g. an 8-byte-aligned-int is requested. (Probably breaks too much.) * Disallow arrays of extra-aligned types, and array references and pointer arithmetic on such types; either with an error, or with a warning and removal of the aligned attribute (in the case of arrays, attaching it to the array; in the case of pointers, causing the results of the arithmetic to have the ordinary type without alignment). We could also add a target_aligned attribute which can be used to describe the alignment of a pointer's target, to use for pointers to the start of an array where the start is aligned but the individual elements aren't. As well as allowing e.g. to define functions taking such pointer arguments, this would also allow refined rules: an array of an extra-aligned type has the alignment passed to the array (with a warning); pointers to extra-aligned types have the extra alignment removed from the target type in favour of a target_aligned attribute on the pointer; extra-aligned-array decays to target_aligned pointer; arithmetic on target_aligned pointers loses the target_aligned attribute unless GCC can prove that the value being added is a multiple of the extra alignment. I think this, properly implemented and ideally with the problems applying attributes to array parameters dealt with, would cover all the semantics people might want to specify except if they really do want alignment attributes to increase the size of the types being aligned. -- What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug target/21042] Error when compiling jdk14
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:18 --- Well first report it to freebsd since that is where you got GCC from in the first place and it is a modifed compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug tree-optimization/19637] Missed constant propagation with placement new
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 16:32:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug target/21042] Error when compiling jdk14
--- Additional Comments From samedii at gmail dot com 2005-04-16 16:33 --- thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21042
[Bug tree-optimization/19637] Missed constant propagation with placement new
--- Additional Comments From giovannibajo at libero dot it 2005-04-16 16:38 --- Notice that the frontend shouldn't *ever* call fold. It's the optimizers' job to adjust these things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:38 --- The C++ failures are most likely PR 20931. -- What|Removed |Added BugsThisDependsOn||20931 Component|tree-optimization |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug rtl-optimization/21002] RTL prologue and basic-block reordering pessimizes delay-slot filling
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:44 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 16:44:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21002
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
-- What|Removed |Added GCC build triplet|ppc-apple-darwin7.8 | GCC host triplet|ppc-apple-darwin7.8 | GCC target triplet|ppc-apple-darwin7.8 / avr- |avr |none-none | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug java/21044] [4.0/4.1 Regression] Static class init optimization is broken
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-16 16:45 --- *** This bug has been marked as a duplicate of 12911 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug java/12911] Class initialization optimization pessimization
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-16 16:45 --- *** Bug 21044 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12911
[Bug java/21044] [4.0/4.1 Regression] Static class init optimization is broken
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-16 16:46 --- This is related to, but not the same as, 12911. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:46 --- Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr should be changed to recongize them as such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug middle-end/21059] New: Bogus warning about clobbered variable
$ cat m68k-dis.i
typedef int (*fprintf_ftype) (void *, const char*, ...);
typedef struct disassemble_info {
fprintf_ftype fprintf_func;
void *stream;
int (*read_memory_func) (void);
} disassemble_info;
extern char *foo (void);
typedef struct { } jmp_buf[1];
extern int setjmp (jmp_buf);
int
print_insn_m68k (disassemble_info *info)
{
jmp_buf bailout;
if (setjmp (bailout) != 0)
return -1;
info-fprintf_func (info-stream, foo ());
return 0;
}
$ gcc/xgcc -B gcc/ -W -Wall -O2 -S m68k-dis.i -v
Reading specs from gcc/specs
Target: ia64-suse-linux
Configured with: ../configure --host=ia64-suse-linux --enable-shared
--enable-threads --enable-__cxa_atexit --with-system-zlib
--with-system-libunwind
Thread model: posix
gcc version 4.0.0 20050416 (prerelease)
gcc/cc1 -fpreprocessed m68k-dis.i -quiet -dumpbase m68k-dis.i -auxbase
m68k-dis -O2 -W -Wall -version -o m68k-dis.s
GNU C version 4.0.0 20050416 (prerelease) (ia64-suse-linux)
compiled by GNU C version 4.0.0 20050416 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
m68k-dis.i: In function ôòøprint_insn_m68kôòù:
m68k-dis.i:11: warning: argument ôòøinfoôòù might be clobbered by
ôòølongjmpôòù or ôòøvforkôòù
--
Summary: Bogus warning about clobbered variable
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug java/21044] [4.0/4.1 Regression] Static class init optimization is broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:57 --- This is a dup of bug 18399, the problem comes from recursively inlining. *** This bug has been marked as a duplicate of 18399 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug java/18399] [4.0/4.1 Regression] Class initialization optimization does not work with the inliner
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:57 --- *** Bug 21044 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug java/18399] [4.0/4.1 Regression] Class initialization optimization does not work with the inliner
-- What|Removed |Added Target Milestone|4.1.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug tree-optimization/20922] missed always false conditional
--- Additional Comments From phython at gcc dot gnu dot org 2005-04-16 17:12 --- Created an attachment (id=8654) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8654action=view) Fold stuff -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |phython at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
[Bug tree-optimization/17217] not removing removal of nested structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 17:37 --- Fixed in 4.1.0 and above by Daniel's aliasing improvements. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17217
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-04-16 17:50 --- (In reply to comment #41) Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline to resolve Josh's bootstrap failure. Sounds like you've already done the necessary testing, and I'll trust you on a suitable ChangeLog entry. I'm not convinced. 1) It produces non-canonical RTL: (MINUS (REG) (const)) 2) It doesn't validate that insn, which is necessary in case 'const' or some modified version of it is not valid. R. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Additional Comments From schlie at comcast dot net 2005-04-16 18:22 --- Subject: Re: Initializing string literal data improperly marked frame-relative?, should be readonly static const. Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr should be changed to recongize them as such. Actually the problem seems then be that literal string constants aren't being consistently defined through CONST_DECL's (just as initializing char array data, which are equivalent to string initializers, and all other literal and static constants which end up being stored as literal data are); for which MEM_READONLY_P allows all memory references to, to be easily identified, which seems to be it's intent. Is there any reason that literal string constant data shouldn't be similarly declared and correspondingly identifiable? (or just an oversight?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Additional Comments From schlie at comcast dot net 2005-04-16 18:41 --- Subject: Re: Initializing string literal data improperly marked frame-relative?, should be readonly static const. From: Paul Schlie [EMAIL PROTECTED] Subject: Re: [Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const. Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr should be changed to recongize them as such. Actually the problem seems then be that literal string constants aren't being consistently defined through CONST_DECL's (just as initializing char array data, which are equivalent to string initializers, and all other literal and static constants which end up being stored as literal data are); for which MEM_READONLY_P allows all memory references to, to be easily identified, which seems to be it's intent. Is there any reason that literal string constant data shouldn't be similarly declared and correspondingly identifiable? (or just an oversight?) I suspect it was likely an artifact of the now depreciated writeable-strings extension, which previously pretended that literal string constants were not READONLY after being copied from the executable image into read/write memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug c++/21060] New: Symbol for static member of template is not emitted.
For a static member of a template class, the symbol doesn't appear to be
emitted.
For example, with the code:
/*BEGIN CODE*/
#include stdio.h
template class T
class Base {
public:
static int bob;
T a;
Base() { printf(Base::Base starting\n); fflush(stdout); }
~Base() { printf(Base::~Base::bob = %d\n, Base::bob); fflush(stdout); }
};
template class T
int BaseT::bob = 10;
int main() {
Basefloat b;
fflush(stdout);
return 0;
}
/*END CODE*/
if you attempt to compile directly to an executable, you get the following
error:
/usr/bin/ld: Undefined symbols:
Basefloat::bob
collect2: ld returned 1 exit status
If you compile to object code (with -c option) and then use nm to dump the
symbols, you get:
m0135:/tmp olsonse$ nm -a bobby.o
U __Unwind_Resume
U __ZN4BaseIfE3bobE
0088 t __ZN4BaseIfEC1Ev
00d8 t __ZN4BaseIfED1Ev
U ___gxx_personality_v0
U ___sF
U _fflush
T _main
U _printf
U dyld_stub_binding_helper
Note that the Base::bob is indicated to be Undefined. If I use an earlier
compile on the same system (3.3.x), Base::bob is definitely shown as being
present.
--
Summary: Symbol for static member of template is not emitted.
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olsonse at umich dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.8.0
GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: powerpc-apple-darwin7.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21060
[Bug c++/21060] Symbol for static member of template is not emitted.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:05 --- This is a dup of bug 11026 which is fixed for 4.0.0. *** This bug has been marked as a duplicate of 11026 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21060
[Bug target/11026] [Darwin] g++ does not instantiate static data members of templates
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:05 --- *** Bug 21060 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||olsonse at umich dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11026
[Bug fortran/21061] New: gfortran ignores -Werror
Said option has no effect. -- Summary: gfortran ignores -Werror Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran 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=21061
[Bug tree-optimization/21048] [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:20 --- Andrew could you look into this and see why the use info is not being updated correctly? Also note the patch in comment #4 is only working around the buggyness of the use information not being updated correctly. -- What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug fortran/21061] gfortran ignores -Werror
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:26 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 19:26:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21061
[Bug java/21022] bootstrap error compiling libgcj with awt support on darwin-ppc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:53 --- Confirmed on x86-pc-linux-gnu with compiling the generated GdkFontMetrics.class from gcj build with the following command line. gcj -S -gstabs -findirect-dispatch GdkFontMetrics.class -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 19:53:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug java/21022] bootstrap error compiling libgcj with awt support on darwin-ppc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 20:07 --- Here is the backtrace: #0 fold_convert (type=0xb7bf8288, arg=0x0) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fold- const.c:1883 #1 0x083be08f in bit_from_pos (offset=0xb7bf8288, bitpos=0xb7bf8288) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/stor-layout.c:538 #2 0x083d176f in bit_position (field=0xb7c37510) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ tree.c:1495 #3 0x081ce78e in dbxout_type (type=0xb7c2abd0, full=0) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/dbxout.c:1406 #4 0x081ce46e in dbxout_type (type=0xb7c2ad80, full=1) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/dbxout.c:2112 #5 0x081d21ea in dbxout_symbol (decl=Variable decl is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/dbxout.c:2534 #6 0x083f2df2 in rest_of_decl_compilation (decl=0xb7c2ae58, top_level=1, at_end=0) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/passes.c:249 The field decl which is being taken the bit position of: field_decl 0xb7c37510 font type pointer_type 0xb7c2d288 type record_type 0xb7c2d144 java.awt.Font type_4 DI size integer_cst 0xb7bf1408 constant invariant 64 unit size integer_cst 0xb7c0c708 constant invariant 8 align 32 symtab 21 alias set -1 fields field_decl 0xb7c3506c D.487 pointer_to_this pointer_type 0xb7c2d288 chain type_decl 0xb7c2d21c java.awt.Font unsigned SI size integer_cst 0xb7bf1360 constant invariant 32 unit size integer_cst 0xb7bf1180 constant invariant 4 align 32 symtab 20 alias set -1 pointer_to_this pointer_type 0xb7c3757c ignored decl_1 VOID file gnu/java/awt/peer/gtk/GdkFontMetrics.java line 74 align 1 offset_align 1 context record_type 0xb7c2abd0 java.awt.FontMetrics chain field_decl 0xb7c31948 D.454 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug java/21022] bootstrap error compiling libgcj with awt support on darwin-ppc
--- Additional Comments From andreast at gcc dot gnu dot org 2005-04-16 20:16 --- I just built the tree without awt-gtk enabled. The gnu/java/awt/peer/gtk/GdkFontMetrics.class is built even without gtk enabled. So, a command line compile of the class to .o is possible and makes the bug easier to reproduce for others. As Andrew P already mentioned. On darwin I reproduce the bug this way: /Volumes/src/gcc/gcc-cvs/objdir/./gcc/jc1 gnu/java/awt/peer/gtk/GdkFontMetrics.class -fhash-synchronization -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase GdkFontMetrics.class -auxbase GdkFontMetrics -g -O2 -Wno-deprecated -version -fclasspath= -fbootclasspath=/Volumes/src/gcc/gcc-cvs/objdir/powerpc-apple-darwin7.9.0/libjava:/Volumes/src/gcc/gcc-cvs/gcc/libjava:/Volumes/src/gcc/gcc-cvs/gcc/libjava/external/w3c_dom:/Volumes/src/gcc/gcc-cvs/gcc/libjava/external/sax -fencoding=UTF-8 -findirect-dispatch -fjni -o /var/tmp//ccA7zDFV.s It happens on both, 4.0 and 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug c++/21056] Linker errors when deriving from std::iostream
--- Additional Comments From james dot kanze at free dot fr 2005-04-16 21:00 --- Subject: Re: Linker errors when deriving from std::iostream pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 13:12 --- Fixed but really this is binutils bug but oh well. Actually, I sort of suspected as much. I wasn't 100% sure, but I think I compiled and linked the same thing on a Sparc Solaris without problems. I hesitated sending it to you, but I didn't know who else to address myself to. (You guys seem serious about quality and usability, which isn't always the case. Even, all too often, when you pay for it. Despite my occasional criticisms, I really appreciate what you're doing.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21056
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-16 21:42 --- Subject: Bug 20126 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-16 21:42:27 Modified files: gcc: ChangeLog loop.c Log message: PR target/20126 * loop.c (loop_givs_rescan): Handle non-replaceable (plus (reg) (const)). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8324r2=2.8325 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop.c.diff?cvsroot=gccr1=1.526r2=1.527 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16
21:48 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 15, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline
to resolve Josh's bootstrap failure. Sounds like you've already done
the necessary testing, and I'll trust you on a suitable ChangeLog entry.
Thanks, here's what I've just checked in.
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR target/20126
* loop.c (loop_givs_rescan): Handle non-replaceable (plus (reg)
(const)).
Index: gcc/loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.526
diff -u -p -r1.526 loop.c
--- gcc/loop.c 10 Apr 2005 04:00:45 - 1.526
+++ gcc/loop.c 16 Apr 2005 21:40:02 -
@@ -5488,6 +5488,15 @@ loop_givs_rescan (struct loop *loop, str
loop_insn_emit_before (loop, 0, v-insn,
gen_move_insn (*v-location,
v-new_reg));
+ else if (GET_CODE (*v-location) == PLUS
+ REG_P (XEXP (*v-location, 0))
+ CONSTANT_P (XEXP (*v-location, 1)))
+ loop_insn_emit_before (loop, 0, v-insn,
+ gen_move_insn (XEXP (*v-location, 0),
+ gen_rtx_MINUS
+ (GET_MODE (*v-location),
+ v-new_reg,
+ XEXP (*v-location, 1;
else
{
/* If it wasn't a reg, create a pseudo and use that. */
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/2703] Internal error #20000409 for g++-3.0 (20010423)
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-16 21:50 --- Not fixed in 3.4.4 -- What|Removed |Added Status|RESOLVED|REOPENED Known to fail||2.95.3 3.0.4 3.2.3 3.3.6 ||3.4.4 Known to work||4.0.0 4.1.0 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2703
[Bug c++/21026] ICE in check_tag_decl, at cp/decl.c:3516
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-16 21:51 --- *** This bug has been marked as a duplicate of 2703 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21026
[Bug c++/2703] Internal error #20000409 for g++-3.0 (20010423)
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-16 21:51 --- *** Bug 21026 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2703
[Bug c++/2703] Internal error #20000409 for g++-3.0 (20010423)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 21:53 --- But fixed in 4.0.0 so closing as fixed as this is not a regression. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2703
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16
21:58 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 15, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
I agree with your proposed game plan of keeping the hard failure in
place temporarily, to discover whether there are any other fallback
strategies that would be useful. Ultimately though, I don't think we
should close PR20126 until a soft failure is implemented on mainline,
like we've (Jakub has) done on the gcc-4_0-branch (such as the
mainline code proposed in comment #30).
But see, the problem with the soft failure mode is that, if it is ever
legitimate to leave the giv alone and not make sure we set whatever
register appears in it to the right value, then can't we always do it,
removing all of the (thus useless) workarounds?
And if there's any case in which it is not legitimate to do so, then
the soft failure mode would be a disservice to the user, that would
silently get a miscompiled program. We should probably at least warn
in this case.
Anyhow, here's a patch that was tested with bootstrap and regtest on
amd64-linux-gnu on mainline, that brings in the soft failure mode from
the 4.0 branch to mainline, without removing the potentially-useless
workarounds.
Index: gcc/loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.526
diff -u -p -r1.526 loop.c
--- gcc/loop.c 10 Apr 2005 04:00:45 - 1.526
+++ gcc/loop.c 16 Apr 2005 21:37:45 -
@@ -5494,11 +5494,23 @@ loop_givs_rescan (struct loop *loop, str
rtx reg, seq;
start_sequence ();
reg = force_reg (v-mode, *v-location);
- seq = get_insns ();
- end_sequence ();
- loop_insn_emit_before (loop, 0, v-insn, seq);
- if (!validate_change_maybe_volatile (v-insn, v-location, reg))
- gcc_unreachable ();
+ if (validate_change_maybe_volatile (v-insn, v-location, reg))
+ {
+ seq = get_insns ();
+ end_sequence ();
+ loop_insn_emit_before (loop, 0, v-insn, seq);
+ }
+ else
+ {
+ end_sequence ();
+ if (loop_dump_stream)
+ fprintf (loop_dump_stream,
+unable to reduce iv in insn %d\n,
+INSN_UID (v-insn));
+ bl-all_reduced = 0;
+ v-ignore = 1;
+ continue;
+ }
}
}
else if (v-replaceable)
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug middle-end/20739] [4.0 regression] ICE in gimplify_addr_expr
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16 21:58 --- Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on cv-qual diffs On Apr 15, 2005, Jeffrey A Law [EMAIL PROTECTED] wrote: On Thu, 2005-04-14 at 14:02 -0300, Alexandre Oliva wrote: On Apr 4, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote: If the operands of a cond-expr used as an lvalue differ in cv qualification, the front-end adds nop_exprs to add cv qualifiers that the gimplifier drops when simplifying (T const)*v. The `' was added by gimplify_cond_expr. The problem is that gimplify_addr_expr gimplifies its operand in such a way that the nop_expr is dropped, and nothing puts it back in, so when we test that, in the indirect_ref case in gimplify_addr_expr, the types are compatible, the test fails because of the missing cv-qualifier in the pointed-to type. This patch fixes this. Ok to install if bootstrap and regtest on amd64-linux-gnu pass? Bootstrap and regtest pased on amd64-linux-gnu, at least for mainline. I'm retesting on the branch, since I'm not entirely sure I actually tested it there. Approved for mainline. Mark has final call on the branch. Thanks, Roger had already approved it for mainline, but not yet for the branch. Mark? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug libfortran/19872] [4.0 only] closed and re-opened file not overwriten
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug bootstrap/20155] [4.0/4.1 Regression] libgcj build fails with execvp: /bin/sh: Argument list too long
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
[Bug java/18212] nativ compilation with multiple jars fails / gives internal compiler error
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18212
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug c++/19884] [3.3/3.4 regression] ICE on explicit instantiation of a non-template constructor
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19884
[Bug c++/19608] [3.4 Regression] ICE after friend function definition in local class
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19608
[Bug c++/19004] ICE in uses_template_parms at cp/pt.c:4860
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19004
[Bug testsuite/21062] New: Incorrect declaration of printf() in alias2.C
See attached patch.
My GCC superpowers aren't quite up to analyzing this, but I suppose this would
cause problems for e.g. the i2pk target as it would receive size=0 in its
arguments in the function below.
If this can't be sorted out by trivial inspection, please let me know and I'll
run some tests.
/* Returns the number of bytes of arguments automatically
popped when returning from a subroutine call.
FUNDECL is the declaration node of the function (as a tree),
FUNTYPE is the data type of the function (as a tree),
or for a library call it is an identifier node for the subroutine name.
SIZE is the number of bytes of arguments passed on the stack. */
int
ip2k_return_pops_args (tree fundecl ATTRIBUTE_UNUSED, tree funtype, int size)
{
if (TREE_CODE (funtype) == IDENTIFIER_NODE)
return size;
if (TYPE_ARG_TYPES (funtype) == NULL_TREE
|| (TREE_VALUE (tree_last (TYPE_ARG_TYPES (funtype))) == void_type_node))
return size;
return 0;
}
--
Summary: Incorrect declaration of printf() in alias2.C
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oyvind dot harboe at zylin dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21062
[Bug testsuite/21062] Incorrect declaration of printf() in alias2.C
--- Additional Comments From oyvind dot harboe at zylin dot com 2005-04-16 22:05 --- Created an attachment (id=8661) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8661action=view) Fixes declaration of printf() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21062
[Bug libfortran/14325] [libgfortran] libgfortran does not build with newlib on arm-elf (stdint.h does not define the right types)
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14325
[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
[Bug libfortran/15235] libgfortran doesn't build on Solaris
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15235
[Bug libfortran/16991] [meta-bug] libgfortran does not build every where
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16991
[Bug middle-end/16670] struct { type:0; } passing bugs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 22:37 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16670
[Bug middle-end/19590] IVs with the same evolution not eliminated
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2005-01-23 16:27:34 |2005-04-16 22:40:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug fortran/21063] New: internal compiler error in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
Here's the piece of code: program bug real, dimension(100) :: dummy real, dimension(100) :: foo integer :: i do i=1,100 call random_number(dummy(i)) call random_number(foo(i)) end do write(*,*) foo(maxloc(dummy)) end program and the output. bash-2.05b$ gfc bug.f90 bug.f90: In function 'MAIN__': bug.f90:12: internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 Please submit a full bug report, bash-2.05b$ gfc --version GNU Fortran 95 (GCC 4.1.0 20050416 (experimental)) Copyright (C) 2005 Free Software Foundation, Inc. -- Summary: internal compiler error in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guillemborrell at yahoo dot es CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug middle-end/17961] ICE for operation on small vector with altivec enabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 22:54 --- This is weird in that it works on ppc-darwin, maybe the altivec ABI is changing something or the just the ABI difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug SWING/21064] New: StyleContext.addStyle causes NullPointerException
The (to-be-shortly) attached testcase (which works with JDK 1.4.x) causes a NullPointerException: $ gcj -o SwStyle SwStyle.java --main=SwStyle -g $ ./SwStyle Exception in thread main java.lang.ExceptionInInitializerError at java.lang.Class.initializeClass() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at SwStyle.main(java.lang.String[]) (/tmp/SwStyle.java:12) at gnu.java.lang.MainThread.call_main() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) Caused by: java.lang.NullPointerException at java.util.Hashtable.put(java.lang.Object, java.lang.Object) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.SimpleAttributeSet.addAttribute(java.lang.Object, java.lang.Object) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext.addAttribute(javax.swing.text.AttributeSet, java.lang.Object, java.lang.Object) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext$NamedStyle.setResolveParent(javax.swing.text.AttributeSet) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext$NamedStyle.StyleContext$NamedStyle(javax.swing.text.StyleContext, java.lang.String, javax.swing.text.Style) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext.addStyle(java.lang.String, javax.swing.text.Style) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at SwStyle.clinit() (/tmp/SwStyle.java:8) at java.lang.Class.initializeClass() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) ...3 more This is using the gcc-4.0 branch; I haven't tested head. (This testcase is simplified from JEmacs.) -- Summary: StyleContext.addStyle causes NullPointerException Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: SWING AssignedTo: graydon at redhat dot com ReportedBy: bothner at gcc dot gnu dot org 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=21064
[Bug SWING/21064] StyleContext.addStyle causes NullPointerException
--- Additional Comments From bothner at gcc dot gnu dot org 2005-04-16 23:05 --- Created an attachment (id=8662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8662action=view) Testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21064
[Bug target/21051] [4.1 Regression] sync tests ICE on ia64
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 23:16:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21051
[Bug target/21051] [4.1 Regression] sync tests ICE on ia64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-16 23:19 --- Subject: Bug 21051 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-16 23:19:35 Modified files: gcc: ChangeLog builtins.c gcc/config/ia64: sync.md Log message: PR target/21051 * builtins.c (expand_builtin) BUILT_IN_BOOL_COMPARE_AND_SWAP_*: Use the mode of boolean_type_node when the user doesn't provide one. * config/ia64/sync.md (sync_lock_releaseI48MODE): Use operand 1. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8325r2=2.8326 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gccr1=1.454r2=1.455 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/sync.md.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21051
[Bug target/21051] [4.1 Regression] sync tests ICE on ia64
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-16 23:20 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21051
[Bug fortran/21063] internal compiler error in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 23:22 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-04-16 23:22:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug java/21065] New: javax.swing.event.EventListenerList.getListenerList() implemented wrong
I am using a custom Class wich throws events, by using this I rely on the
EventListenerList Class to hold my Eventlisteners. The Method getListenerList is
used by the method
protected void fireFooXXX() {
// Guaranteed to return a non-null array
Object[] listeners = listenerList.getListenerList();
// Process the listeners last to first, notifying
// those that are interested in this event
for (int i = listeners.length-2; i=0; i-=2) {
if (listeners[i]==FooListener.class) {
// Lazily create the event:
if (fooEvent == null)
fooEvent = new FooEvent(this);
((FooListener)listeners[i+1]).fooXXX(fooEvent);
}
}
}
which is the standard Method given in the API to fire Events to all
EventListeners. This Method relies on the correct implementation of
getListenerList() which should according to the API Documentation of Java by SUN
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/event/EventListenerList.html#getListenerList()
[quote]
getListenerList
public Object[] getListenerList()
Passes back the event listener list as an array of ListenerType-listener
pairs. Note that for performance reasons, this implementation passes back the
actual data structure in which the listener data is stored internally! This
method is guaranteed to pass back a non-null array, so that no null-checking is
required in fire methods. A zero-length array of Object should be returned if
there are currently no listeners. WARNING!!! Absolutely NO modification of the
data contained in this array should be made -- if any such manipulation is
necessary, it should be done on a copy of the array returned rather than the
array itself.
[/quote]
The API doc says Passes back the event listener list as an array of
ListenerType-listener pairs. my understanding of pairs is multiples of two, so
the EventListenerList can never contain 1 or 3 entries or any other odd number.
But when adding one Eventlistener to such a list it really just adds this
EventListener resulting in a getListenerList() which returns one Element, which
is simply wrong.
A Testcase will follow as soon as I have written one.
btw this is my system: WinXP SP2
gcj 4.0 20050324 from thisiscool.com
Regards,
Andreas
--
Summary: javax.swing.event.EventListenerList.getListenerList()
implemented wrong
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gruni dot ca at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21065
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From roger at eyesopen dot com 2005-04-17 00:21 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail Hi Alex, On 16 Apr 2005, Alexandre Oliva wrote: On Apr 15, 2005, Roger Sayle [EMAIL PROTECTED] wrote: I agree with your proposed game plan of keeping the hard failure in place temporarily, to discover whether there are any other fallback strategies that would be useful. Ultimately though, I don't think we should close PR20126 until a soft failure is implemented on mainline, like we've (Jakub has) done on the gcc-4_0-branch (such as the mainline code proposed in comment #30). But see, the problem with the soft failure mode is that, if it is ever legitimate to leave the giv alone and not make sure we set whatever register appears in it to the right value, then can't we always do it, removing all of the (thus useless) workarounds? And if there's any case in which it is not legitimate to do so, then the soft failure mode would be a disservice to the user, that would silently get a miscompiled program. We should probably at least warn in this case. I don't believe there are any cases in which it is not legitimate to leave the GIV alone, so we'll never silently miscompile anything. My understanding is that it's always possible to leave the giv alone (provided that we set all_reduced to false). The workarounds as we've got used to calling them are not required for correctness, but for aggressive optimization. There's clearly a benefit to strength reducing GIVs, and the harder we try to replace them, the better the code we generate. Yes, they are (useless/not necessary) from a purely correctness point of view; we don't even have to call validate_change we could just always give-up and punt using clearing all_reduced (technicaly we don't have to perform any loop optimizations for correctness), but we'd generate pretty poor code. The patch you proposed provides the soft failure mode we want (and now have on the release branch). We could, as you say remove all of the current workarounds, and the only thing that would suffer is the quality of the code we generate. Needless to say, I'd prefer to keep these optimizations (for example your recent one for Josh to allow us to strength reduce the ARM's stim instruction). It's not unreasonable to try three or four approaches before giving up, and forcing the optimizers to preserve the original GIV. Does this clear things up? Do you agree? Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug libgcj/20693] javax-imageio.lo failed to build
--- Additional Comments From green at redhat dot com 2005-04-17 00:42 --- I'm seeing this same problem. GCC4 won't build reliably without this fix. -- What|Removed |Added CC||green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20693
[Bug java/21065] javax.swing.event.EventListenerList.getListenerList() implemented wrong
--- Additional Comments From gruni dot ca at gmail dot com 2005-04-17 00:45 --- Created an attachment (id=8663) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8663action=view) Simple Testcase showing that addind a EventListener increments the list by one This is a testcase I wrote, I compiled it with gcj --main=GcjEventListenerListTest -o EventTest.exe GcjEventListenerListTest.java the output should be similar to JDK if implemented correctly JDK output: should be=2 is=2 should be=4 is=4 GCJ output: should be=2 is=1 should be=4 is=2 That's all I have -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21065
[Bug java/21065] javax.swing.event.EventListenerList.getListenerList() implemented wrong
-- What|Removed |Added Attachment #8663|Simple Testcase showing that|Simple Testcase showing that description|addind a EventListener |adding a EventListener |increments the list by one |increments the list by one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21065
[Bug middle-end/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 01:38 --- Subject: Bug 21024 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-17 01:38:28 Modified files: gcc: ChangeLog builtins.c fold-const.c Log message: PR middle-end/21024 * builtins.c (expand_builtin_strcat): Convert the result of strlen to the right type. * fold-const.c (fold_binary) PLUS_EXPR: Use fold_convert to avoid creating type mismatches. GE_EXPR: Pass op0 and op1 to fold_build2 to avoid creating type mismatches. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8326r2=2.8327 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gccr1=1.455r2=1.456 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.561r2=1.562 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug middle-end/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-17 01:41 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
-- Bug 21021 depends on bug 21024, which changed state. Bug 21024 Summary: fold generates a comparison of two operands whose types do not match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug middle-end/20739] [4.0 regression] ICE in gimplify_addr_expr
--- Additional Comments From mark at codesourcery dot com 2005-04-17 02:36 --- Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on cv-qual diffs Alexandre Oliva wrote: Thanks, Roger had already approved it for mainline, but not yet for the branch. Mark? OK for 4.0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17 02:37 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 16, 2005, Roger Sayle [EMAIL PROTECTED] wrote: Does this clear things up? Do you agree? Yup, for both questions. Thanks for the clarification. It wasn't clear to me that the assignments played any useful role, as soon as I found out the givs could be assumed to hold the correct value. It all makes sense to me now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From mark at codesourcery dot com 2005-04-17 02:43 --- Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned)) jsm28 at gcc dot gnu dot org wrote: --- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-16 16:15 --- Much the same issue can arise with array references through pointer-to-aligned-type, and with arithmetic on such pointers, as does with array-of-aligned-type. Agreed. The obvious options include: * Make a new type of larger size to match the alignment whenever e.g. an 8-byte-aligned-int is requested. (Probably breaks too much.) * Disallow arrays of extra-aligned types, and array references and pointer arithmetic on such types; either with an error, or with a warning and removal of the aligned attribute (in the case of arrays, attaching it to the array; in the case of pointers, causing the results of the arithmetic to have the ordinary type without alignment). As a C front-end maintainer, which of these options do you prefer? It sounds like you, like me, favor the second option, but I'd like to be sure. We could also add a target_aligned attribute which can be used to describe the alignment of a pointer's target, to use for pointers to the start of an array where the start is aligned but the individual elements aren't. That sounds plausible, but should, IMO, be done after first implementing one of your options above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug tree-optimization/20929] [4.0 Regression] internal compiler error: verify_stmts failed.
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 02:44 --- This patch is OK for 4.0.0 RC2. Please apply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20929
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 02:46 --- Jakub, thank you for applying this patch to the 4.0 branch. If you've confirmed that the bug has been fixed, would you please remove 4.0 from the summary here, and from the known-to-fail list? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
