[Bug target/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #4 from arjan at linux dot intel dot com 2006-07-29 07:46 --- fixed in current SVN -- arjan at linux dot intel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug target/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
-- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
GNU Emacs crashes when computing a square root
Hello! I don't want to register as bugzilla for this case so I am using this interface. Recently I compiled GNU Emacs 22.0.50 with Apple's gcc 4.0.1 on Mac OS X 10.4.7 for a PowerPC 7447A processor with particularly these options: -faltivec -mcpu=7450 -mpowerpc -mpowerpc-gpopt -mpowerpc-gfxopt Leaving away -faltivec, gcc complained about optimising for different CPU subtypes. Keeping it, an executable Emacs was made, but when launching it without windows it crashed when it had to compute a square root. In windows mode in X11 when I let Emacs calculate a square root in Lisp, it crashed, too. To me it seems as if it is necessary to add a warning about using the -faltivec switch. It seems it delegates floating point computations to a library that is not supplied by Apple, but could be part of the Metrowerks compilers the switch is meant to support. -- Greetings Pete »¿ʇı̣ əsnqɐ ʇ,uɐɔ noʎ ɟı̣ ɓuı̣ɥʇʎuɐ sı̣ pooɓ ʇɐɥʍ«
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #7 from schwab at suse dot de 2006-07-29 09:34 --- Broken by r90624. Reproduced with -O -floop-optimize2 -fmove-loop-invariants. 2004-11-14 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/18431 * tree-flow.h (stmt_references_memory_p): Declare. * tree-ssa-loop-im.c (stmt_cost): Use stmt_references_memory_p. * tree-ssa.c (stmt_references_memory_p): New function. -- schwab at suse dot de changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug libstdc++/27530] Possible memory leak in std::vector::reserve() or std::vector::clear()
--- Comment #6 from chris at bubblescope dot net 2006-07-29 10:08 --- My natural suspision would be that your clone() function is incorrectly implemented. Can you show us the source to the CMessage object, and theMessageFactory.createInstance( )? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-29 10:32 --- Zdenek's patch also can't be responsible for this. He probably also just uncovered latent bugs. Instead of pointing at random patches, it would be much more helpful to analyze what is going wrong. For this kind of problem, you can be almost sure that the real bug is in the ia64 backend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #5 from tbm at cyrius dot com 2006-07-29 10:45 --- Created an attachment (id=11964) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11964&action=view) test case Testcase from application "kvirc". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-29 10:57 --- Please stop adding test cases!!! :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-07-26 08:05:42 |2006-07-29 10:57:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #9 from schwab at suse dot de 2006-07-29 11:05 --- At least we know that the bug is also present in 4.0. -- schwab at suse dot de changed: What|Removed |Added Known to fail|4.2.0 |4.0.3 4.1.1 4.2.0 Known to work|4.0.3 4.1.1 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug tree-optimization/28411] "Illegal instruction" error with -ftrapv
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-07-29 11:47 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01213.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||07/msg01213.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28411
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #33 from hubicka at gcc dot gnu dot org 2006-07-29 13:14 --- Subject: Bug 28071 Author: hubicka Date: Sat Jul 29 13:14:22 2006 New Revision: 115810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115810 Log: PR rtl-optimization/28071 * cfgrtl.c (rtl_delete_block): Free regsets. * flow.c (allocate_bb_life_data): Re-use regsets if available. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/flow.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug java/28531] New: [win32] serialisation is broken on mingw (works on linux)
gcj (GCC) 4.2.0 20060726 (experimental) Deserialize an object fails on Class.forName(). I assumed this would work because class.forName() doesn't use the stack unwinder any longer. Exception: Exception in thread "main" java.lang.ClassNotFoundException: Serialisation at java.lang.Class.forName(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/lang/natClass.cc:91) at java.io.ObjectInputStream.resolveClass(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:800) at java.io.ObjectInputStream.readClassDescriptor(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:551) at java.io.ObjectInputStream.readObject(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:245) at java.io.ObjectInputStream.readObject(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:292) at Serialisation.read(D:/programming/javaCompiler/code/tests/1_console/2_serialisation/Serialisation.java:43) at Serialisation.main(D:/programming/javaCompiler/code/tests/1_console/2_serialisation/Serialisation.java:21) -- Summary: [win32] serialisation is broken on mingw (works on linux) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531
[Bug java/28531] [win32] serialisation is broken on mingw (works on linux)
--- Comment #1 from mtrudel at gmx dot ch 2006-07-29 13:38 --- Created an attachment (id=11965) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11965&action=view) Simple serialisation test A simple serialisation program to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531
[Bug java/28533] New: [ecj] Default warnings
ecj has a lot of default warnings on that are a bit obnoxious. It would be nice to have a set of default warnings that people would actually use (currently it seems people just disable them all). GNU Classpath for example disables all the following to get more sane warning results: -warn:-deprecation,serial,typeHiding,unchecked,unused,varargsCast Especially the serial and unused (imports) warnings don't add much value since they cannot point out any coding mistake. They would be nice options for a lint like tool though. -- Summary: [ecj] Default warnings Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28533
[Bug java/28533] [ecj] Default warnings
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-07-29 15:41 --- Is there a way to map ecj's warnings options onto gcc's existing warning flags? -w -W -Wextra ? deprecation == -Wno-deprecated-declarations serial == ?? typeHiding == -Wshadow unchecked == ? unused == -Wunused (but for importing packages, hmmm) varargsCast == ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28533
[Bug middle-end/28473] [4.0/4.1 Regression] with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
--- Comment #10 from sayle at gcc dot gnu dot org 2006-07-29 19:07 --- Subject: Bug 28473 Author: sayle Date: Sat Jul 29 19:07:40 2006 New Revision: 115812 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115812 Log: PR middle-end/28473 Backport from mainline. * convert.c (convert_to_integer): When transforming (T)foo(x) into bar(x) check that bar's result type can represent all the values of T. * builtins.c (fold_fixed_mathfn): When long and long long are the same size, canonicalize llceil*, llfloor*, llround* and llrint* functions to their lceil*, lfloor*, lround* and lrint* forms. * gcc.dg/fold-convround-1.c: New test case. * gcc.dg/builtins-55.c: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/builtins-55.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/fold-convround-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c branches/gcc-4_1-branch/gcc/convert.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug libmudflap/28536] New: Reading or assigning global h_errno variable causes a memory violation report
I've submitted this bug more than 1 year ago at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163306. Now I can supply
new information: I just confirmed that the bug still exists in latest official
release version 4.1.1 as well as in a gcc trunk build from today "gcc (GCC)
4.2.0 20060729 (experimental)". Had I realised last year that this is a problem
in the compiler per se and not in any GNU/Linux distribution, I would have
probably entered the bug here in the first place.
I copy / paste here from the other URL. Note that there are existing comments
there.
How reproducible:
Always
Steps to Reproduce:
1. Compile the program
#include
#include
int main()
{
printf("%d", h_errno);
return 0;
}
and the program
#include
int main()
{
h_errno = 0;
return 0;
}
with mudflap enabled, i.e.
gcc -fmudflap prog1.c -lmudflap -o prog1
and
gcc -fmudflap prog2.c -lmudflap -o prog2
2. Run prog1 and prog2.
Actual Results: When prog1 is run, this is what I get:
***
mudflap violation 1 (check/read): time=1121380261.574621 ptr=0xb7eff6b4 size=4
pc=0xb7f09322 location=`a.cpp:6 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x44) [0xb7f09322]
./a.out(main+0x81) [0x8048839]
/usr/lib/libmudflap.so.0(__wrap_main+0x1d8) [0xb7f0a04e]
Nearby object 1: checked region begins 17B after and ends 20B after
mudflap object 0x80cb430: name=`errno area'
bounds=[0xb7eff6a0,0xb7eff6a3] size=4 area=static check=0r/0w liveness=0
alloc time=1121380261.574591 pc=0xb7f09e0a
number of nearby objects: 1
When prog2 is run, the report is similar, but it says "(check/write)", instead
of "(check/read)" -- because h_errno is written to.
Expected Results: There should have been no violation messages.
--
Summary: Reading or assigning global h_errno variable causes a
memory violation report
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vesselinpeev at hotmail dot com
GCC host triplet: UNCO Running large program compiled with
mudflap abort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28536
[Bug middle-end/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #20 from patchapp at dberlin dot org 2006-07-29 20:30 --- Subject: Bug number PR27770 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01215.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #9 from debian-gcc at lists dot debian dot org 2006-07-29 22:28 --- Created an attachment (id=11967) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11967&action=view) patch combined and bootstrapped with the two patches mentioned in #8 with no regressions on i486-linux-gnu. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug libgcj/26910] re-merging java.util.zip
--- Comment #3 from mark at gcc dot gnu dot org 2006-07-29 22:55 --- I don't think this is fixed yet. It seems libgcj and classpath still have different nflaterInputStream implementations. See also the following thread were they were supposed to be merged, but a regression was found and the merge was reverted: http://developer.classpath.org/pipermail/classpath-patches/2006-March/000940.html -- mark at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26910
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #7 from tbm at cyrius dot com 2006-07-29 23:59 --- Created an attachment (id=11968) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11968&action=view) test case Testcase from application "rlwarp". This one is especially for Steven. :) FWIW, it's smaller than any other testcase so far. Oh, and I have two more to come... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #34 from patchapp at dberlin dot org 2006-07-30 05:45 --- Subject: Bug number PR rtl-optimization/28071 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01221.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c++/28539] New: granted access to private nested class
g++ compile such code without any warrnings:
class C {
private:
class N {
public:
N(int val) { this->value = val; }
int getValue() { return value; }
private:
int value;
};
N nO;
public:
C() : nO(17) {}
N &getNestedPrivateObject() {
return nO;
}
};
int main()
{
C o;
return o.getNestedPrivateObject().getValue();
}
--
Summary: granted access to private nested class
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28539
