[Bug fortran/28890] ICE on write
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-09-11 08:15 --- The patch did not apply cleanly to 4.1; I will take a look tonight to try to understand why. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28890
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #14 from victork at il dot ibm dot com 2006-09-11 08:16 --- I will look if patch http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01171.html fixes this one too and will remap it to 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier
--- Comment #2 from mark at gcc dot gnu dot org 2006-09-11 09:39 --- Subject: Re: New: gcj generates a MetalLookAndFeel class that fails cacao's verifier Hi, On Mon, 2006-09-11 at 06:05 +, cam-gcc-bugzilla at aka dot mcc dot id dot au wrote: > When compiling GNU classpath (CVS 20060901) with gcj, I get a > java.lang.VerifyError when running a Swing app with cacao: That is almost certainly a byte code generation bug in gcj. Could you try to recompile GNU Classpath with a different compiler (configure --with-jikes or --with-ecj) if you have one installed to double check? Thanks, Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29013
[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier
--- Comment #3 from cam-gcc-bugzilla at aka dot mcc dot id dot au 2006-09-11 09:44 --- Created an attachment (id=12223) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12223&action=view) MetalLookAndFeel.class as produced by ecj Hi Mark. Indeed, compiling it with ecj results in a class file that is usable (attached). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29013
[Bug ada/29015] New: Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
$ uname -a
Linux rogue 2.6.16-gentoo-r13 #1 PREEMPT Tue Aug 1 13:59:12 GMT 2006 i686 AMD
Athlon(TM) XP 2000+ GNU/Linux
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/home/laguest/opt/gcc-4.1.1
--enable-libada --enable-languages=c,c++,java,objc,ada
Thread model: posix
gcc version 4.1.1
$ gnatmake -gnat05 -gnatwj test_observers.adb
gcc -c -gnat05 -gnatwj test_observers.adb
+===GNAT BUG DETECTED==+
| 4.1.1 (i686-pc-linux-gnu) Assert_Failure atree.adb:812 |
| Error detected at subjects.ads:17:3 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
test_observers.adb
my_observer.ads
observers.ads
subjects.ads
compilation abandoned
gnatmake: "test_observers.adb" compilation error
with My_Observer;
with Subjects;
procedure Test_Observers is
Obs : Observers.Observer_Access := new My_Observer.My_Observer_Type;
Subject : Subjects.Subject;
begin
-- Subjects.Attach(Subject, Obs);
Subject.Attach(Obs);
Subject.Notify;
end Test_Observers;
package body My_Observer is
procedure Update(Self : in My_Observer_Type) is
begin
Ada.TexT_IO.Put_Line("[My_Observer.Update]");
end Update;
end My_Observer;
with Observers;
package My_Observer is
type My_Observer_Type is new Observers.Observer with private;
procedure Update(Self : in My_Observer_Type);
private
type My_Observer_Type is new Observers.Observer with null record;
end My_Observer;
limited with Observers;
with Ada.Containers.Doubly_Linked_Lists;
with Ada.Finalization;
package Subjects is
type Subject is new Ada.Finalization.Limited_Controlled with private;
procedure Attach(Self : in out Subject'Class; Observer : access
Observers.Observer);
procedure Detach(Self : in out Subject'Class; Observer : access
Observers.Observer);
procedure Notify(Self : in Subject);
private
function Equals(Left, Right : access Observers.Observer) return Boolean;
package Observer_Lists is new
Ada.Containers.Doubly_Linked_Lists(Observers.Observer_Access, Equals);
type Subject is new Ada.Finalization.Limited_Controlled with
record
Observer_List : Observer_Lists.List;
end record;
end Subjects;
with Observers;
package body Subjects is
use type Observer_Lists.Cursor;
-- Add an observer to this subject's internal list.
procedure Attach(Self : in out Subject'Class; Observer : access
Observers.Observer) is
begin
Self.Observer_List.Append(New_Item => Observer);
end Attach;
-- Remove an observer from this subject's internal list.
procedure Detach(Self : in out Subject'Class; Observer : access
Observers.Observer) is
Position : Observer_Lists.Cursor := Self.Observer_List.Find(Observer);
begin
if Position /= Observer_Lists.No_Element then
Self.Observer_List.Delete(Position);
end if;
end Detach;
-- Notify all observers who are monitoring this subject that something has
happened.
procedure Notify(Self : in Subject) is
Current : Observer_Lists.Cursor := Self.Observer_List.First;
begin
while Current /= Observer_Lists.No_Element loop
Observer_Lists.Element(Current).Update;
Current := Observer_Lists.Next(Current);
end loop;
end Notify;
function Equals(Left, Right : access Observers.Observer) return Boolean is
begin
if Left = Right then
return True;
end if;
return False;
end Equals;
end Subjects;
package Observers is
type Observer is abstract tagged private;
type Observer_Access is access all Observers.Observer'Class;
procedure Update(Self : in Observer) is abstract;
private
type Observer is abstract tagged null record;
end Observers;
--
Summary: Ada 2005 observer pattern with mutually dependent
packages and containers produces compiler error
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laguest at abyss2 dot demon dot co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http:
[Bug target/29004] Wrong Code for ARM IRQ routine
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41 --- *** This bug has been marked as a duplicate of 16634 *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29004
[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ")))
--- Comment #3 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41 --- *** Bug 29004 has been marked as a duplicate of this bug. *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||hans dot buchmann at fhso ||dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
[Bug rtl-optimization/28243] [4.1 Regression] internal consistency failure when building fontforge with -O3 -fPIC -ftracer
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-11 10:42 --- > Here's another test case, taken from maxdb: Please do not attach "other" testcases to a PR, the underlying problems are very likely unrelated. Only testcases reduced from the original one are of any help. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28243
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #4 from dorit at il dot ibm dot com 2006-09-11 10:57 --- > You could help by looking at the source code (there are only a few dozens > places mentioning flag_unsafe_math_optimizations) and auditing which places > would be more suited to a new flag_reassociate_fp variable. we'd be very interested in allowing the vectorizer to work under flag_reassociate_fp rather than flag_unsafe_math_optimizations, so we'll give this a try. -- dorit at il dot ibm dot com changed: What|Removed |Added CC||eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #5 from eres at il dot ibm dot com 2006-09-11 11:21 --- Hi, Following Dorit's comment; We thought of starting this journey with a patch that include the cases in the vectorizer and loop-unroll and gradually add the rest of the cases that can go under flag_reassociate_fp. Revital -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug c++/29016] New: ICE when compiling with -Os
ICE with gcc version 4.2.0 20060911 (experimental) when optimizing for code size. Preprocessed example code follows. Compile with: g++ -Os -c foo.cc -o foo.o 20060908 worked ok. -- Summary: ICE when compiling with -Os Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: us15 at os dot inf dot tu-dresden dot de GCC build triplet: i486-slackware-linux GCC host triplet: i486-slackware-linux GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug c++/29016] ICE when compiling with -Os
--- Comment #1 from us15 at os dot inf dot tu-dresden dot de 2006-09-11 11:23 --- Created an attachment (id=12224) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12224&action=view) Example testcase This code triggers the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ")))
--- Comment #4 from tbm at cyrius dot com 2006-09-11 11:31 --- (In reply to comment #2) > Patch here: > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00230.html What's the status of this patch? -- tbm at cyrius dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #6 from eres at il dot ibm dot com 2006-09-11 11:49 --- I would also like to be assigned to this bug. Thanks, Revital -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug c++/29016] ICE when compiling with -Os
--- Comment #2 from tbm at cyrius dot com 2006-09-11 11:54 --- I guess you mean this ICE: /home/uas/cvs/drops/l4/kernel/fiasco/src/kern/kern_cnt.cpp:109: internal compiler error: tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224 Please submit a full bug report, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug c++/29016] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
--- Comment #3 from tbm at gcc dot gnu dot org 2006-09-11 11:59 ---
(sid)451:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-g++ -c pr29016.cc
(sid)452:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-g++ -c -O pr29016.cc
pr29016.cc:16: internal compiler error: tree check: expected class
'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
zsh: exit 1 x86_64-unknown-linux-gnu-g++ -c -O pr29016.cc
(sid)453:[EMAIL PROTECTED]: ~] cat pr29016.cc
typedef unsigned long int Mword;
class Kern_cnt
{
private:enum
{
Max_slot = 2,
};
static Mword (*read_kcnt_fn[Max_slot]) ();
private:static Mword read_kcnt1 ();
static Mword read_kcnt2 ();
}
__attribute__ ((packed));
Mword (*Kern_cnt::read_kcnt_fn[Max_slot]) () =
{
read_kcnt1, read_kcnt2};
(sid)454:[EMAIL PROTECTED]: ~]
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i486-slackware-linux|
GCC host triplet|i486-slackware-linux|
GCC target triplet|i486-slackware-linux|
Last reconfirmed|-00-00 00:00:00 |2006-09-11 11:59:48
date||
Summary|ICE when compiling with -Os |tree check: expected class
||'expression', have
||'exceptional' (baselink) in
||get_base_var, at ipa-
||utils.c:224
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #6 from rearnsha at arm dot com 2006-09-11 12:14 --- Subject: Re: compiler generates incorrect ARM instructions when using long bitfields On Wed, 2006-08-02 at 13:56, jason dot morgan at vpnsolutions dot uk dot com wrote: > Where do I obtain EABI and what effect will it have on my toolchain? http://www.arm.com/products/DevTools/ABI.html > Is there any plan or project to merge the resolution to PR23623 back into gcc > 4.1.1 No, this doesn't fit the critera for a regression, so it won't be fixed in FSF releases. However, I think the CodeSourcery distributions have this feature in a 4.1 build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug c++/29017] New: %s substituted with different untranslated words can't be properly translated
In gcc/cp/typeck.c there is this code
pedwarn ("ISO C++ forbids %s between pointer of type % "
"and pointer-to-function", location);
"Location" will be different, English and untranslated, values depending on how
this code is reached. The result can not be properly translated. Even if
"location" was translated, it surely would not work in all languages to
compose a sentence like this. Please make separate and complete error messages
for each case.
--
Summary: %s substituted with different untranslated words can't
be properly translated
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goeran at uddeborg dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29017
[Bug libfortran/19273] No automatic dependencies in libgfortran
-- pbrook at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pbrook at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19273
[Bug middle-end/25261] [gomp] Nested function calls in #pragma omp parallel blocks
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-11 14:22 ---
I believe OMP_PARALLEL handling in tree-nested.c isn't the only problem, see
e.g.:
extern void abort (void);
void
foo (int *j)
{
int i = 5;
int bar (void) { return i + 1; }
#pragma omp sections private (i)
{
#pragma omp section
{
i = 6;
if (bar () != 7)
#pragma omp atomic
++*j;
}
#pragma omp section
{
if (bar () != 6)
#pragma omp atomic
++*j;
}
}
}
int
main (void)
{
int j = 0;
#pragma omp parallel num_threads (2)
foo (&j);
if (j)
abort ();
return 0;
}
My understanding is that even the OMP_PRIVATE clause in the worksharing
construct
should result in a different FRAME. Another testcase:
extern void abort (void);
extern int omp_get_thread_num ();
extern void omp_set_dynamic (int);
int
main (void)
{
int j = 0, k = 6, l = 7, m = 8;
void
foo (void)
{
int i = 5;
int bar (void) { return i + 1 + (j > 100 ? 1 : 0); }
#pragma omp sections private (i)
{
#pragma omp section
{
i = 6;
if (bar () != 7)
#pragma omp atomic
++j;
}
#pragma omp section
{
if (bar () != 6)
#pragma omp atomic
++j;
}
}
if (k != 6 + omp_get_thread_num () || l != 7 || m != 9)
#pragma omp atomic
++j;
}
omp_set_dynamic (0);
#pragma omp parallel num_threads (2) firstprivate (k) shared (l) private (m)
{
if (omp_get_thread_num () != 0)
k += omp_get_thread_num ();
m = 9;
foo ();
}
if (j)
abort ();
return 0;
}
I believe in many cases we will have to force use_pointer_in_frame when OpenMP
constructs are involved in the parent routines of nested functions. We don't
need it if either all the variables in FRAME structure are shared (then we can
pass around a pointer to the parent's FRAME), or if all are private (then we
could create a completely new copy of the FRAME and make the private vars live
in there), but as soon as things start to get mixed, we need to use pointers.
But not sure how easy would be to figure it out. As convert_nonlocal_reference
already needs to know if it should use pointer or a var directly, we'd need
another flag_openmp pass before walk_all_functions (convert_nonlocal_reference,
root); that would perhaps stick all vars mentioned in omp clauses in some hash
table in struct nesting_info and then use that as a guide to
use_pointer_in_frame.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org,
||dnovillo at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25261
[Bug java/28754] [4.2 regression] java.lang.nullPointerException while accessing final static members of an interface
--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-11 15:08 --- I tried to look at this today but the test is missing a main method (I could work around the lack of a Makefile, but this is more serious...) -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28754
[Bug c++/29016] [4.2 Regression] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|tree check: expected class |[4.2 Regression] tree check: |'expression', have |expected class 'expression', |'exceptional' (baselink) in |have 'exceptional' |get_base_var, at ipa- |(baselink) in get_base_var, |utils.c:224 |at ipa-utils.c:224 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug c++/29016] [4.2 Regression] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-11 15:29 --- This is why I mentioned BASELINK should be stripped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug c++/29016] [4.2 Regression] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug middle-end/25261] [gomp] Nested function calls in #pragma omp parallel blocks
--- Comment #4 from jakub at gcc dot gnu dot org 2006-09-11 15:46 ---
Furthermore, I have no idea what would:
extern void abort (void);
int
baz (int (*bar) (void))
{
return bar ();
}
void
foo (int *j)
{
int i = 5;
int (*fn) (void);
int bar (void) { return i + 1; }
fn = bar;
if (bar (fn) != 6)
#pragma omp atomic
++j;
#pragma omp sections private (i)
{
#pragma omp section
{
i = 6;
if (baz (fn) != 7)
#pragma omp atomic
++*j;
}
#pragma omp section
{
if (baz (fn) != 6)
#pragma omp atomic
++*j;
}
}
}
int
main (void)
{
int j = 0;
#pragma omp parallel num_threads (2)
foo (&j);
if (j)
abort ();
return 0;
}
be supposed to do. Do other openmp compilers support nested C functions? If
so,
what they are doing here? It would be easy to say that e.g. all non-local vars
in nested functions are implicitly shared (i.e. we always reference the
original
parent function's variables, not any remapped ones). But can we do the same in
Fortran where nested functions are part of the standard?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25261
[Bug c++/29017] %s substituted with different untranslated words can't be properly translated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 15:53 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-09-11 15:53:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29017
[Bug c++/29018] New: empty enum accepted
The c++ parser accepts:
enum { };
which is specifically listed in clause 7 paragraph 3 of the C++ standard as
ill-formed.
--
Summary: empty enum accepted
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug c++/29018] empty enum accepted
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 16:09 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|3.2.3 4.1.0 4.2.0 |3.2.3 4.1.0 4.2.0 2.95.3 ||3.0.4 3.4.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-09-11 16:09:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3
--- Comment #4 from janis at gcc dot gnu dot org 2006-09-11 16:19 --- Sorry, I don't have an ia64 system on which to try wrong-code tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #7 from roger at eyesopen dot com 2006-09-11 16:36 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00406.html -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-11 16:36:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug bootstrap/28784] [4.2 regression] Bootstrap comparison failure
--- Comment #6 from roger at eyesopen dot com 2006-09-11 16:52 --- I believe I have a patch. I'm just waiting for the fix for PR28672 (which I've just approved) to be applied, so I can complete bootstrap and regression test to confirm there are no unexpected side-effects. -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-11 16:52:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28784
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #39 from dje at gcc dot gnu dot org 2006-09-11 17:05 --- Subject: Bug 27287 Author: dje Date: Mon Sep 11 17:05:15 2006 New Revision: 116850 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116850 Log: 2006-09-11 Guenter Roeck <[EMAIL PROTECTED]> David Edelsohn <[EMAIL PROTECTED]> PR target/27287 * config/rs6000/spe.md (frob_df_di): Remove %H. (frob_di_df): Remove %H. Change evmergelo to mr. (frob_di_df_2): Remove %H. Change evldd to two loads. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/spe.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug libgomp/28046] libgomp test pr27337.C fails intermittently
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-11 17:11:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28046
[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3
--- Comment #5 from sje at cup dot hp dot com 2006-09-11 17:12 --- I will see if I can find the checkin on the 4.1 branch that caused the failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
[Bug middle-end/28096] fdlibm/strtod.c miscompiled at -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug middle-end/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #9 from tromey at gcc dot gnu dot org 2006-09-11 17:49 --- Created an attachment (id=12225) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12225&action=view) preprocessed source Added a self-contained .i file Compile with -O2 => fails Compile with -g => works -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug middle-end/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #10 from tromey at gcc dot gnu dot org 2006-09-11 18:01 --- Created an attachment (id=12226) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12226&action=view) valgrind report -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug middle-end/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #11 from tromey at gcc dot gnu dot org 2006-09-11 18:06 --- I compiled with -O1 and ran valgrind; the results were clean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug rtl-optimization/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-11 18:18 --- -O2 -fno-gcse works. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug fortran/21061] gfortran ignores -Werror
--- Comment #3 from aldot at gcc dot gnu dot org 2006-09-11 18:26 --- -pedantic-errors also has no effect. From a quick look, it does not occur in fortran/* at all and should probably be removed. I'm preparing an updated patch to add proper -Werror support that emits 'Warning' for warnings and treats them as errors. The patch from #2 emitted the string 'Error' instead, so may not be appropriate. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21061
[Bug testsuite/28969] FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization 2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-11 18:56 --- http://gcc.gnu.org/ml/gcc-cvs/2006-09/msg00240.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28969
[Bug java/29019] New: ?
Hello, Excuse me for my English because I learn English. I have found a bug for convert a *.java to *.exe. When I would like use getCanonicalPath()or getCanonicalFile() from class File in Java, I have a different results with the *.class and the *.exe. I use Windows XP Home Edition. Can you contact me when the bug is repaired? Thanks you very much -- Summary: ? Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: belegkarnil at gmail dot com GCC build triplet: ? GCC host triplet: ? GCC target triplet: ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29019
[Bug fortran/28276] EXPONENT() broken for real constants
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 19:19 ---
Subject: Re: EXPONENT() broken for real constants
On Sun, Sep 10, 2006 at 10:43:21PM -, tobias dot burnus at physik dot
fu-berlin dot de wrote:
>
> Comment #5 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-10
> 22:43 ---
> > Can you try this patch? It required MPFR 2.2.0.
> Tested on openSUSE/AMD64 with current gfortran trunk + patch and mpfr-2.2.0-9.
>
> It works ok with kind = 4 and kind = 8. However, with kind = 10 I get a
> NaN for
> print *, scale (fraction (a), exponent (a)) / a
>
> My test case:
>
> integer, parameter :: k = 10
> real(k), parameter :: one = 1.0_k
> real(k) :: a
> a = one
> print *, "This ratio should be 1:"
> print *, scale (fraction (a), exponent (a)) / a
> end
>
>
gfortran is calling the wrong libm function. -fdump-tree-original
on FreeBSD shows
{
real10 D.1254;
D.1254 = scalbn(_gfortran_fraction_r10(a10),_gfortran_exponent_r10(a10))/a10;
_gfortran_transfer_real (&dt_parm.2, &D.1254, 10);
}
That should be scalbnl(). I'll see if I can track down the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug c++/29020] New: [4.0/4.1/4.2 regression] ICE using A::A instead of A in friend declaration
The following (IMHO valid) code snippet triggers a segfault since GCC 3.4.0:
==
template struct A
{
void foo();
};
struct B
{
template friend void A::A::foo();
};
==
x1.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Before the code was accepted.
--
Summary: [4.0/4.1/4.2 regression] ICE using A::A instead of
A in friend declaration
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:28 --- Subject: Bug 28726 Author: ebotcazou Date: Mon Sep 11 19:28:11 2006 New Revision: 116855 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116855 Log: PR rtl-optimization/28726 * sched-deps.c (sched_analyze_reg): New function extracted from... (sched_analyze_1): ...here. Call it to analyze references to registers. Treat again writes to a stack register as writing to the register. (sched_analyze_2): ...and here. Call it to analyze references to registers. Treat again reads of a stack register as reading the register. Added: trunk/gcc/testsuite/gcc.dg/pr28726.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:28 --- Subject: Bug 28726 Author: ebotcazou Date: Mon Sep 11 19:28:41 2006 New Revision: 116856 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116856 Log: PR rtl-optimization/28726 * sched-deps.c (sched_analyze_reg): New function extracted from... (sched_analyze_1): ...here. Call it to analyze references to registers. Treat again writes to a stack register as writing to the register. (sched_analyze_2): ...and here. Call it to analyze references to registers. Treat again reads of a stack register as reading the register. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr28726.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/sched-deps.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:32 --- Fixed in upcoming 4.1.2 release. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00415.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug fortran/28276] EXPONENT() broken for real constants
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 19:33 ---
Subject: Re: EXPONENT() broken for real constants
On Mon, Sep 11, 2006 at 07:19:41PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
>
> gfortran is calling the wrong libm function. -fdump-tree-original
> on FreeBSD shows
>
> {
> real10 D.1254;
>
> D.1254 =
> scalbn(_gfortran_fraction_r10(a10),_gfortran_exponent_r10(a10))/a10;
> _gfortran_transfer_real (&dt_parm.2, &D.1254, 10);
> }
>
> That should be scalbnl(). I'll see if I can track down the bug.
>
I should also note that the parsing is correct as shown by -fdump-parse-tree
ASSIGN MAIN__:a10 1._10
ASSIGN MAIN__:a10 (/ __scale_10[[((__fraction_10[[((MAIN__:a10))]])
(__exponent_10[[((MAIN__:a10))]]))]] MAIN__:a10)
So it's the translation of __scale_10 to scalbnl.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug c++/29021] New: [4.0/4.1/4.2 regression] ICE on invalid use of "*" in template
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
struct A
{
template void foo()
{
A().template *foo<0>();
}
};
==
bug.cc: In member function 'void A::foo()':
bug.cc:5: error: expected unqualified-id before '*' token
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Without the template keyword the compiler ICEs without a suitable error
message:
==
struct A
{
template void foo()
{
A().*foo<0>();
}
};
==
bug.cc: In member function 'void A::foo()':
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid use of "*" in
template
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
[Bug c++/29021] [4.0/4.1/4.2 regression] ICE on invalid use of "*" in template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
[Bug c++/29020] [4.0/4.1/4.2 regression] ICE using A::A instead of A in friend declaration
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
[Bug c++/29022] New: [4.0/4.1/4.2 regression] ICE using operator int in invalid class hierarchy
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
struct A
{
operator int();
};
struct B : virtual A, A<0> {};
int foo(B &b)
{
return b;
}
==
bug.cc:6: error: expected template-name before '<' token
bug.cc:6: error: expected `{' before '<' token
bug.cc:6: error: expected unqualified-id before '<' token
bug.cc: In function 'int foo(B&)':
bug.cc:10: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE using operator int in
invalid class hierarchy
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/29022] [4.0/4.1/4.2 regression] ICE using operator int in invalid class hierarchy
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug rtl-optimization/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #13 from dannysmith at users dot sourceforge dot net 2006-09-11 19:47 --- In my sources for David Gay's gdtoa implemntation it say this: /* On a machine with IEEE extended-precision registers, it is * necessary to specify double-precision (53-bit) rounding precision * before invoking strtod or dtoa. If the machine uses (the equivalent * of) Intel 80x87 arithmetic, the call * _control87(PC_53, MCW_PC); * does this with many compilers. Whether this or another call is * appropriate depends on the compiler; for this to work, it may be * necessary to #include "float.h" or another system-dependent header * file. */ There is a variant of strtod in the gdtoa file strtodnrp.c: /* This is a variant of strtod that works on Intel ia32 systems */ /* with the default extended-precision arithmetic -- it does not */ /* require setting the precision control to 53 bits. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug rtl-optimization/28965] distribute_notes fails to change REG_DEAD into REG_UNUSED notes for global registers
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-09-11 19:50 ---
(In reply to comment #2)
> Please provide a testcase as well as the other required bits of info.
>
This is a stripped down cc1plus testcase:
void
f (unsigned char *a, int &i)
{
i = a[0] << 8 & a[1];
}
This doesn't actually trigger the 'global variable' part, but distribute_notes
fails to see that there is a set because it looks at PATTERN (tem), when it
should be looking at tem, and thus fails to see a REG_INC note.
The invalid REG_DEAD note triggered an ICE during sched1 with a 4.1.1 based
compiler with ENABLE_CHECKING set, compiling for sh4-elf with -O2
-fno-exceptions.
I can replicate the invalid REG_DEAD note with vanilla 4.1-2006-03-21,
although of course it won't ICE, since checking is disabled.
This insn appears in the combine dump:
(insn 13 8 14 0 (set (reg:QI 162)
(mem:QI (post_inc:SI (reg/v/f:SI 159 [ a ])) [0 S1 A8])) 182 {movqi_i}
(
insn_list:REG_DEP_TRUE 6 (nil))
(expr_list:REG_UNUSED (reg:QI 162)
(expr_list:REG_DEAD (reg/v/f:SI 159 [ a ])
(expr_list:REG_INC (reg/v/f:SI 159 [ a ])
(nil)
The testcase doesn't trigger with 4.2, but that's because we don't have
a post-increment in the same place; the distribute_notes code is still wrong
there.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|-00-00 00:00:00 |2006-09-11 19:50:45
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28965
[Bug c/29023] New: Incorrect optimization of redundant expressions in || expression
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,objc
--prefix=/software/linux/gcc/4.0.3
Thread model: posix
gcc version 4.0.3
The bug shows up with options -Os or -Ox (x >= 1). Here is the source file:
main () {
unsigned char t1[1];
t1[0] = 128;
if (((unsigned char) (t1 [0] & 128) != 128) ||
((unsigned char) (t1 [0] & 128) != 128)
) printf ("Not Ok\n");
else printf ("Ok\n");
}
The bug also occurs in 3.4.6, but does not occur in 3.2.3. I have not tested
it on a compiler newer than 4.0.3.
--
Summary: Incorrect optimization of redundant expressions in ||
expression
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Paul dot F dot Dietz at motorola dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29023
[Bug c++/29024] New: storage class specifier accepted for typedef (clause 7.1.1 ; 1)
The following requires a diagnostic: typedef static int T; -- Summary: storage class specifier accepted for typedef (clause 7.1.1 ; 1) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
[Bug fortran/28276] EXPONENT() broken for real constants
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2006-09-11 20:31 --- Subject: Re: EXPONENT() broken for real constants On Mon, Sep 11, 2006 at 07:33:35PM -, sgk at troutmask dot apl dot washington dot edu wrote: > > I should also note that the parsing is correct as shown by -fdump-parse-tree > > > ASSIGN MAIN__:a10 1._10 > ASSIGN MAIN__:a10 (/ __scale_10[[((__fraction_10[[((MAIN__:a10))]]) > (__exponent_10[[((MAIN__:a10))]]))]] MAIN__:a10) > > So it's the translation of __scale_10 to scalbnl. > I have a patch for this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug ada/29025] New: gcc 4.1.1: procedure doesn't modify a parameters of type 'in out'
GCC configure data: system type... i686-pc-cygwin target system type... powerpc-xcoff-lynxos build system type... i686-pc-cygwin gcc -v Reading specs from /cross_compiler/tools/cygwin_ppc_gnu/lib/gcc/ppc-xcoff-lynxos/4.1.1/specs Target: ppc-xcoff-lynxos Configured with: gcc-4.1.1/configure --target=ppc-xcoff-lynxos --verbose --prefix=/cross_compiler/tools --exec-prefix=/cross_compile r/tools/cygwin_ppc_gnu --with-gnu-as --with-gnu-ld --with-sysroot=/cross_compiler/tools/cygwin_ppc_gnu/ppc-xcoff-lynxos --enable-lan guages=c,ada --enable-threads=gnat --disable-multilib --enable-shared --with-cpu=750 -v Thread model: lynx gcc version 4.1.1 GCC ADA version 4.1.1 I have an erroneous behaviour of the GCC-ADA compiler when a procedure having the parameter 'in out' is called passing, has argument, a component of a record (nested record) having a representation clause. The 'in out' parameter, modified by the procedure, at the caller level remains unchanged. Without one representation clause (specifyed below) the behaviuor is corret. I attached the source file necessary to repeat the problem. The package pkg_test.adb contains the code having wrong behaviour. The procedure prova call (at line 61) the procedure Set_3D_NotEngJust passing as argument 'T.DATA.INT_3D_TRACK_DATA.NOT_ENG_PROP_JUSTIFICATION' (packed bit array 0..31 of boolean). The procedure Set_3D_NotEngJust change the corresponding Into parameter (in out) but, at the end of the procedure, the parameter 'T.DATA.INT_3D_TRACK_DATA.NOT_ENG_PROP_JUSTIFICATION' doesn't have the values modified. Without the representation clause reported in file MSG_TYPES_S at line 489: INT_3D_TRACK_DATA at 4 * UNITSIZE range 0 .. (201 * 16) - 1; the error is not present. I use the following command: gcc -S pkg_test.adb to examine the assembler. Examining the asm source code produced by gcc (I dont have many experience in the PPC assembler) it seems that the compiler pass the argument by value and not by reference as the 'Passed_By_Reference attribute instead report. Without the representation clause at line 489 the parameter is passed by reference. Passing the parameter by copy the compiler add 2 asm instruction: . line #843 stw 0,88(31) . line #844 addi 0,31,88 that modify the correct value in the r0 register producing the error. I have tryed to modifiy the procedure prova by adding the following asm instruction lwz 0,88(31) lwz 9,952(31) stw 0,234(9) after the call of the procedure Set_3D_NotEngJust (line 62) and the program works correctly. If I reduce the number of the fields of the record REC_INTERNAL_3D_TRACK_DATA eliminate the fields after KILL_PROBABILITY the program works correctly. One workaround found to allows the compiler to produce the correct code is adding the folowing pragma: pragma export_procedure (Internal => Set_3D_NotEngJust, External => "Set_3D_NotEngJust", Mechanism => (Into => Value, TheReason => Value)); In this manner the parameters are always passed by value and the problem doesn't arise. Please doesn't esitate to mail me for any further information you need. PS: sorry for my english -- Summary: gcc 4.1.1: procedure doesn't modify a parameters of type 'in out' Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mbo dot massimo at tiscali dot it GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: powerpc-xcoff-lynxos http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug ada/29025] gcc 4.1.1: procedure doesn't modify a parameters of type 'in out'
--- Comment #1 from mbo dot massimo at tiscali dot it 2006-09-11 20:36 --- Created an attachment (id=12227) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12227&action=view) source files to reproduce the problem source file necessary to reproduce the bug. Use gcc -S pkg_test.adb command to produce the .s files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug ada/29025] gcc 4.1.1: procedure doesn't modify a parameters of type 'in out'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3
--- Comment #6 from sje at cup dot hp dot com 2006-09-11 20:39 --- It looks like this failure was introduced with r115620. +2006-07-20 Paul Brook <[EMAIL PROTECTED]> + + Backport from mainline. + PR 27363 + * cse.c (cse_insn): Add destination addresses to hash table. Check if + they are invalidated by this instruction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
[Bug middle-end/29023] Incorrect optimization of redundant expressions in || expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 20:48 --- Fixed in 4.0.4 20060622. This was either a dup of bug 26729 or bug 28045. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29023
[Bug c++/29024] [4.0/4.1/4.2 Regression] storage class specifier accepted for typedef (clause 7.1.1 ; 1)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 20:50 --- Confirmed, a regression from 3.4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 3.0.4 2.95.3 3.3.3 ||3.2.3 Last reconfirmed|-00-00 00:00:00 |2006-09-11 20:50:09 date|| Summary|storage class specifier |[4.0/4.1/4.2 Regression] |accepted for typedef (clause|storage class specifier |7.1.1 ; 1) |accepted for typedef (clause ||7.1.1 ; 1) Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
--- Comment #7 from sg313d at gmail dot com 2006-09-11 20:57 --- Thank you for the fix. And for serving the GCC to the community. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug libstdc++/29026] New: std::basic_istream<>::sentry() fails to catch when reading whitespace
27.6.1.1 P4 says that formatted input functions should set badbit if a call to fetch characters from the streambuf throws an exception. The implementation of this in bits/istream.tcc is done after the sentry is constructed. But the sentry's constructor may try to read whitespace, and it is not doing any exception handling, so ios_base::badbit is not getting set in this case. -- Summary: std::basic_istream<>::sentry() fails to catch when reading whitespace Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jimrees at itasoftware dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace
--- Comment #1 from jimrees at itasoftware dot com 2006-09-11 21:07 --- Created an attachment (id=12228) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12228&action=view) bug reproducer program bug reproducer, compile with g++ - any flags, but do not disable exceptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug libffi/23935] $PREFIX/include/ffi.h needs to go to a target- and -version-dependent location
-- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-11 21:08:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23935
[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace
--- Comment #2 from jimrees at itasoftware dot com 2006-09-11 21:10 --- fyi, a "real world" example of how this comes up? Construct a std::ifstream using a pathname to a directory instead of a file. Under Linux and MacOS at least, the basic_filebuf code is happy to open such a pathname, but then will get EISDIR when it first tries to read, and will throw an exception. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug c++/29027] New: template conversion specialization found by using declaration
According to clauses 7.3.3 ; 4 and 14.5.2 ; 7, the using declaration below
should elicit a diagnostic, since template conversion function specializations
are not supposed to be found by name lookup.
struct B
{
template < class T > operator T ();
};
struct D: B
{
using B::operator int;
};
--
Summary: template conversion specialization found by using
declaration
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29027
[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace
--- Comment #3 from sebor at roguewave dot com 2006-09-11 21:25 --- This sounds like it might be related to http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309. If so, and if this case is important to you (the submitter) it might be helpful to give the committee a little nudge on comp.std.c++ to make sure the issue gets addressed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug c++/29027] template conversion specialization found by using declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 21:27 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||2.95.3 3.0.4 4.0.0 4.1.0 ||3.4.0 3.2.3 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-09-11 21:27:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29027
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-11 21:30 --- Subject: Bug 28672 Author: hjl Date: Mon Sep 11 21:30:07 2006 New Revision: 116859 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116859 Log: 2006-09-11 Alexandre Oliva <[EMAIL PROTECTED]> PR target/28672 * var-tracking.c (dump_dataflow_set): Start dumping at register zero. (clobber_variable_part): Kill only the variable part in registers holding it, leaving other variables alone. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-11 21:34 --- Subject: Bug 27537 Author: hjl Date: Mon Sep 11 21:34:06 2006 New Revision: 116860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116860 Log: gcc/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 PR target/27537 PR target/28621 * config/i386/i386.c (override_options): Always default to 16 byte stack boundary. gcc/testsuite/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 * gcc.target/i386/pr13685.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr13685.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug target/28621] [4.1 Regression] SIGSEGV in set_fast_math () at -Os
--- Comment #12 from hjl at gcc dot gnu dot org 2006-09-11 21:34 --- Subject: Bug 28621 Author: hjl Date: Mon Sep 11 21:34:06 2006 New Revision: 116860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116860 Log: gcc/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 PR target/27537 PR target/28621 * config/i386/i386.c (override_options): Always default to 16 byte stack boundary. gcc/testsuite/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 * gcc.target/i386/pr13685.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr13685.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #22 from hjl at gcc dot gnu dot org 2006-09-11 21:34 --- Subject: Bug 13685 Author: hjl Date: Mon Sep 11 21:34:06 2006 New Revision: 116860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116860 Log: gcc/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 PR target/27537 PR target/28621 * config/i386/i386.c (override_options): Always default to 16 byte stack boundary. gcc/testsuite/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 * gcc.target/i386/pr13685.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr13685.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug c++/20420] Incorrectly Accepts double declarations
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-09-11 21:45 ---
I suppose this is the same basic problem?
namespace N
{
int i;
}
void
f ()
{
using N::i;
using N::i;
}
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|2.95.3 3.2.3 3.3.1 3.3.4|2.95.3 3.2.3 3.3.1 3.3.4
|3.4.3 4.0.0 |3.4.3 4.0.0 4.2.0
Last reconfirmed|2006-01-20 00:58:45 |2006-09-11 21:45:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20420
[Bug c++/29028] New: No warning about unused names introduced with using declarations
I suppose it would make sense to emit a -Wunused warning for this code:
namespace N
{
int i;
}
void
f ()
{
using N::i;
}
--
Summary: No warning about unused names introduced with using
declarations
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028
[Bug c/29029] New: temporary created for unknown reason
[EMAIL PROTECTED] gujin]$ cat tmp.c
#include
typedef struct {
unsigned short data[3];
union diskcmd {
unsigned udata[5];
unsigned char cdata[20];
} cmd;
} bootloader2_t;
bootloader2_t uninstall_mbr;
extern inline unsigned char
BOOT1_diskread (union diskcmd *str, unsigned buffer)
{
unsigned short status, dummy;
unsigned char returned;
asm volatile (
" movw%%es,%%ax \n"
" pushl %4 \n"
" popw%%bx\n"
" popw%%es\n"
" pushw %%ax\n"
" callw read_disk \n"
" popw%%es\n"
" setc%%dl# set dest to 1 if carry, else clear dest \n"
: "=&a" (status), "=d" (returned), "=S" (dummy)
: "S" (str), "g" (buffer), "d" (str->cdata[2]), "X" (*str)
: "ebx", "edi", "ecx", "memory"
);
return returned;
}
unsigned char BOOT1_uninstall_mbr (void)
{
bootloader2_t copy_in_dataseg;
memcpy (©_in_dataseg, &uninstall_mbr, sizeof (bootloader2_t));
return (BOOT1_diskread (©_in_dataseg.cmd, 0x7c00) != 0);
}
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-2.95.3/bin/gcc
-fomit-frame-pointer -mrtd -Os -c -o tmp.o tmp.c && size tmp.o
textdata bss dec hex filename
69 0 0 69 45 tmp.o
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-3.4.5/bin/gcc
-fomit-frame-pointer -mrtd -Os -c -o tmp.o tmp.c && size tmp.o
textdata bss dec hex filename
67 0 0 67 43 tmp.o
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-4.1.1/bin/gcc
-fomit-frame-pointer -mrtd -Os -c -o tmp.o tmp.c && size tmp.o
textdata bss dec hex filename
93 0 0 93 5d tmp.o
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-4.1.1/bin/gcc
-fomit-frame-pointer -mrtd -Os -S -o tmp.s tmp.c
[EMAIL PROTECTED] gujin]$ cat tmp.s
.file "tmp.c"
.text
.globl BOOT1_uninstall_mbr
.type BOOT1_uninstall_mbr, @function
BOOT1_uninstall_mbr:
pushl %edi
pushl %esi
pushl %ebx
subl$56, %esp
leal8(%esp), %eax
pushl $28
pushl $uninstall_mbr
pushl %eax
callmemcpy
movb18(%esp), %al
leal16(%esp), %esi
movb%al, 7(%esp)
leal36(%esp), %eax
pushl $20
pushl %esi
pushl %eax
callmemcpy
movb7(%esp), %dl
#APP
movw%es,%ax
pushl $31744
popw%bx
popw%es
pushw %ax
callw read_disk
popw%es
setc%dl# set dest to 1 if carry, else clear dest
#NO_APP
xorl%eax, %eax
testb %dl, %dl
movb%dl, 3(%esp)
setne %al
addl$56, %esp
popl%ebx
popl%esi
popl%edi
ret
.size BOOT1_uninstall_mbr, .-BOOT1_uninstall_mbr
.comm uninstall_mbr,28,4
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
Note the _two_ memcpy, a temporary is created identical of "copy_in_dataseg",
even if "copy_in_dataseg" could be used without problem.
If using the -O2 optimisation, the second memcpy() is inlined - but nothing
more.
--
Summary: temporary created for unknown reason
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
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=29029
[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace
--- Comment #4 from jimrees at itasoftware dot com 2006-09-11 22:23 --- Sure, the issue sounds interesting, and the committee's resolution statement is definitely lame. Bug issue 309 seems to be more about what is _specified_ about sentry::sentry()'s behavior, and I don't necessarily care about that w.r.t. this bug. I care about 27.6.1.1 P4 (which makes no mention of sentry), and with the GNU C++ implementation. The fact that operator>>() happens to invoke sentry's constructor does not make an excuse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #15 from sje at cup dot hp dot com 2006-09-11 22:31 --- Bryce, have you looked at ifdef'ing the use of _Unwind_GetIPInfo in the Java library? Would you be willing to do so? I have created an autoconf test (GCC_CHECK_UNWIND_GETIPINFO) in trunk/config/unwind_ipinfo.m4 and the C++ runtime library is checking for HAVE_GETIPINFO before using it. I believe the un-ifdef'ed use of this function in the java library is the reason this PR is still open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug rtl-optimization/28965] distribute_notes fails to change REG_DEAD into REG_UNUSED notes for global registers
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-09-11 19:50:45 |2006-09-11 22:59:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28965
[Bug java/28754] [4.2 regression] java.lang.nullPointerException while accessing final static members of an interface
--- Comment #5 from bero at arklinux dot org 2006-09-11 23:00 --- Created an attachment (id=12229) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12229&action=view) Real test case Oops, must have attached the wrong file, that was the test case for a much older problem (PR24598, which turned out to be compiler flag related) Attaching the real test case that was meant for 28754. I haven't checked yet if it still breaks in current SVN though -- bero at arklinux dot org changed: What|Removed |Added Attachment #12085|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28754
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-11 23:01 --- > Thank you for the fix. And for serving the GCC to the community. :) You're welcome. Thanks for reporting the problem and for the nice testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-11 23:11 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug java/28754] [4.2 regression] java.lang.nullPointerException while accessing final static members of an interface
--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-11 23:26 --- Thanks for the updated test. It fails for me if I compile it to .class with ecj, but not if I compile it to .class with gcj. The difference is in the qualification of the reference to SUFFIX_CLASS in test2 .. ecj generates 3: getstatic #24= but gcj uses test1 as the qualifier. ecj is correct here fwiw. I think the in C++ ABI case we probably should simply initialize the interface that declares the field. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-11 23:26:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28754
[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace
--- Comment #5 from sebor at roguewave dot com 2006-09-12 00:16 --- The reason why I think library issue 309 may be relevant is because while the arithmetic extraction operator>>() is a formatted input function (and thus subject to 27.6.1.1, p4, and required to begin by constructing a sentry object), the sentry ctor is neither a formatted nor unformatted input function, and thus could be considered exempt from the requirements imposed by 27.6.1.1, p4 on the two groups of input functions. The sentry ctor need not even call sgetc() or sbumpc() (e.g., it could call underflow() directly). Further, since the description of the extraction operators clearly separates the initial construction of the sentry from subsequently "obtaining the requested input," an exception thrown during the construction of the sentry could be considered as having occurred prior to "obtaining the requested input" and thus be allowed, in fact required, to propagate to the caller. Note that the impact of the issue isn't just on the extraction operators defined by the library, it affects user-defined extraction operators as well, specifically those that make use of the sentry and that aim to conform to the general iostream exception safety requirements. My "additional comments" on the issue explain how and why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29026
[Bug testsuite/28950] regex wrong for testing on darwin in gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
--- Comment #4 from janis at gcc dot gnu dot org 2006-09-12 00:34 --- Subject: Bug 28950 Author: janis Date: Tue Sep 12 00:34:18 2006 New Revision: 116867 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116867 Log: 2006-09-11 Jack Howarth <[EMAIL PROTECTED]> PR testsuite/28950 * gcc.target/powerpc/ppc-and-1.c: Fix regex. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/ppc-and-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #15 from hjl at lucon dot org 2006-09-12 00:35 --- Fixed: http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00586.html -- hjl at lucon dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug testsuite/28950] regex wrong for testing on darwin in gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
--- Comment #5 from janis at gcc dot gnu dot org 2006-09-12 00:42 --- Subject: Bug 28950 Author: janis Date: Tue Sep 12 00:42:27 2006 New Revision: 116868 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116868 Log: 2006-09-11 Jack Howarth <[EMAIL PROTECTED]> PR testsuite/28950 * gcc.target/powerpc/ppc-and-1.c: Fix regex. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.target/powerpc/ppc-and-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug target/28621] [4.1 Regression] SIGSEGV in set_fast_math () at -Os
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-12 02:54 --- Subject: Bug 28621 Author: hjl Date: Tue Sep 12 02:54:42 2006 New Revision: 116870 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116870 Log: gcc/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 PR target/27537 PR target/28621 * config/i386/i386.c (override_options): Always default to 16 byte stack boundary. gcc/testsuite/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 * gcc.target/i386/pr13685.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr13685.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #23 from hjl at gcc dot gnu dot org 2006-09-12 02:54 --- Subject: Bug 13685 Author: hjl Date: Tue Sep 12 02:54:42 2006 New Revision: 116870 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116870 Log: gcc/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 PR target/27537 PR target/28621 * config/i386/i386.c (override_options): Always default to 16 byte stack boundary. gcc/testsuite/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 * gcc.target/i386/pr13685.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr13685.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #14 from hjl at gcc dot gnu dot org 2006-09-12 02:54 --- Subject: Bug 27537 Author: hjl Date: Tue Sep 12 02:54:42 2006 New Revision: 116870 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116870 Log: gcc/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 PR target/27537 PR target/28621 * config/i386/i386.c (override_options): Always default to 16 byte stack boundary. gcc/testsuite/ 2006-09-11 H.J. Lu <[EMAIL PROTECTED]> PR target/13685 * gcc.target/i386/pr13685.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr13685.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug c++/29028] No warning about unused names introduced with using declarations
--- Comment #1 from bangerth at dealii dot org 2006-09-12 03:58 ---
At first I thought that the warning is not useful since the variable may
in fact not be unused at all -- the using declaration simply makes the
name available in the present scope.
However, then I realized that this also holds here:
void f()
{
extern int i;
}
For this code, we warn, though:
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -Wunused -c x.cc
x.cc: In function ‘void f()’:
x.cc:3: warning: unused variable ‘i’
So for the sake of consistency, we should probably do the same in both
situations, whatever "the same" is here.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-09-12 03:58:07
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028
[Bug c++/20420] Incorrectly Accepts double declarations
--- Comment #5 from bangerth at dealii dot org 2006-09-12 04:00 --- (In reply to comment #4) > I suppose this is the same basic problem? No, that code is definitely legal and unobjectionable. Just as having two extern declarations of the same variable in the same scope (or two forward declarations of a function) is not a problem. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20420
[Bug testsuite/28950] regex wrong for testing on darwin in gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-12 04:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug c++/29001] ICE on invalid return from operator new
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:19 --- 6496 /* Only operator new(...) throw(), can return NULL [expr.new/13]. */ 6497 if ((DECL_OVERLOADED_OPERATOR_P (current_function_decl) == NEW_EXPR 6498 || DECL_OVERLOADED_OPERATOR_P (current_function_decl) == VEC_NEW_EXPR) 6499 && !TYPE_NOTHROW_P (TREE_TYPE (current_function_decl)) 6500 && ! flag_check_new 6501 && null_ptr_cst_p (retval)) Confirmed, retval is NULL here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-12 05:19:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29001
[Bug fortran/28890] ICE on write
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-12 04:37 --- Subject: Bug 28890 Author: pault Date: Tue Sep 12 04:37:09 2006 New Revision: 116871 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116871 Log: 2006-09-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28890 trans-expr.c (gfc_conv_function_call): Obtain the string length of a dummy character(*) function from the symbol if it is not already translated. For a call to a character(*) function, use the passed, hidden string length argument, which is available from the backend_decl of the formal argument. resolve.c (resolve_function): It is an error if a function call to a character(*) function is other than a dummy procedure or an intrinsic. 2006-09-12 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28890 gfortran.dg/assumed_charlen_function_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28890
[Bug target/29030] gcc.dg/array-9.c produces internal compiler error on Darwin at -m64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 04:16 --- This is a target specific issue, I might fix this even though I don't have any way of testing the fix (except maybe for changing the ABI on powerpc-linux-gnu to use the darwin64 struct passing ABI). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
[Bug c/29031] gcc.dg/asm-b.c execution test aborts at -m64 on powerpc-apple-darwin8
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-12 04:43 --- Created an attachment (id=12232) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12232&action=view) assembly file asm-b.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29031
