--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-21 07:21 ---
"Erases all elements with key equivalent to k. Returns the number of elements
erased."
and then:
size_type erase(const key_type& k);
So from that it might not be a bug in libstdc++ as far as I can see.
--
htt
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-01-21 07:21
---
Subject: Bug 25697
Author: jvdelisle
Date: Sat Jan 21 07:21:11 2006
New Revision: 110062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110062
Log:
2006-01-20 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-01-21 07:19
---
Subject: Bug 25697
Author: jvdelisle
Date: Sat Jan 21 07:19:39 2006
New Revision: 110061
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110061
Log:
2006-01-20 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 07:19 ---
Subject: Re: New: GCC rejects the following strictly conforming code with
-ansi -pedantic errors
>
> void foo (const int (*h)[2], int (*i)[2])
> {
> 1 ? h: i;
> }
>
> Also rejected in C99 mode.
ICC warns:
t.c
>
> void foo (const int (*h)[2], int (*i)[2])
> {
> 1 ? h: i;
> }
>
> Also rejected in C99 mode.
ICC warns:
t.c(3): warning #42: operand types are incompatible ("const int (*)[2]" and
"int (*)[2]")
So maybe this is not valid C, I don't know.
-- Pinski
void foo (const int (*h)[2], int (*i)[2])
{
1 ? h: i;
}
Also rejected in C99 mode.
--
Summary: GCC rejects the following strictly conforming code with
-ansi -pedantic errors
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 06:59 ---
I should note that TR1 says erase does take the key by reference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 06:47 ---
I should note that TR1 is a written document. I am wondering what it says
about this case. If it says libstdc++ is right, then maybe you should try to
get it fixed (hard because I hear it is close to approval but I
This happens with both hash_map and unordered_map and their related classes. I
know that hash_map is not standard, and unordered_map is in TR1 so not
considered standard yet.
Here is a kernel of the problem:
hash_map c;
c.insert(...);
hash_map::iterator it = c.find("...");
c.erase(it->fi
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-21 05:19 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 04:15 ---
Confirmed, this also fails on x86_64-linux-gnu which means this is a semi
generic problem.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-21 03:11 ---
No feedback in 3 months.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 03:03 ---
Oh, we still not load PRE this one because we don't handle (*a).b yet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-21 02:54 ---
This is fixed with the toplevel bootstrap but I am waiting for the regressions
associated with the toplevel bootstrap to close this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23927
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.4 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 02:35 ---
(In reply to comment #1)
> I am starting to think the wrong code is a different regression than the
> rejects valid.
I filed that as PR 25895.
--
pinskia at gcc dot gnu dot org changed:
What|Remo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
Testcase:
#include
class base {
public:
base() {}
private:
int val_;
};
class derived : public base {
public:
derived() {}
};
bool x = true ? (derived*)0 : (base*)0;
int main ()
{
if (x)
abort();
}
--
Su
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 02:32 ---
3.3.3 both accepted the code and did not produce the wrong code.
3.4.0 did produce the correct code but rejected the example in comment #0.
The following code is for the wrong code regression which is produceable in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #16 from aoliva at gcc dot gnu dot org 2006-01-21 02:11 ---
Created an attachment (id=10694)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10694&action=view)
Reduced testcase
This reduced testcase triggers the same bug before Richard's patch if compiled
with -fasynchro
Consider this program:
class base {
public:
base() {}
private:
int val_;
};
class derived : public base {
public:
derived() {}
};
template struct static_assert;
template <> struct static_assert {};
int main ()
{
static
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
Some of the new libgomp tests fail initially for this target when tested
with a simulator, for various reasons. This PR tracks them.
Running /home/hp/combined/combined/libgomp/testsuite/libgomp.c/c.exp ...
FAIL: libgomp.c/appendix-a/a.15.1.c execution test
WARNING: program timed out.
FAIL: libgomp
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-21 02:00 ---
I have an even simplier patch which I got from Daniel Berlin instead of "in_ab
= true;" just doing a return will fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25857
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-21 01:48 ---
Patch which I am going to test:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 110030)
+++ tree-ssa-pre.c (working copy)
@@ -2741,10 +
--
jbuck at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--
jbuck at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.1.0
http://gcc.g
--- Comment #1 from jbuck at gcc dot gnu dot org 2006-01-21 01:41 ---
Created an attachment (id=10693)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10693&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
The original report from RMS stated:
"GCC 4 when compiling Emacs gives annoying warnings about
mismatched signs of pointer target types. To turn this
off is not trivial, since the -Wno-pointer-sign option
itself causes a diagnostic from older GCC versions.
It makes compilation fail."
Evidently c
--- Comment #12 from janis at gcc dot gnu dot org 2006-01-21 01:24 ---
A regression hunt of the trunk on powerpc-linux using the testcase in comment
#4 (modified to abort if the result is not 4) identified the following patch to
fix several C++ bugs:
http://gcc.gnu.org/viewcvs?view=rev&
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
Errors in the log look like (for mmix-knuth-mmixware):
Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/gomp/gomp.exp ...
Executing on host: /home/hp/combined/mmixware-sim/gcc/xgcc
-B/home/hp/combined/mmixware-sim/gcc/ /home/hp/combined/combined/gcc/t\
estsuite/gcc.dg/gomp/appendix-a/a.1.1.c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Last known to work with: "Tue Jan 17 02:44:03 UTC 2006 (revision 109801M)".
Known to fail with: "Fri Jan 20 05:17:46 UTC 2006 (revision 110008M)".
Running
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
FAIL: gcc.c-torture/compile/20051228-1.c -O1 (test for excess e
--- Comment #6 from amodra at bigpond dot net dot au 2006-01-21 00:31
---
Fails powerpc64-linux, where I was poking at this bug.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-21 00:27 ---
This also fails on powerpc-darwin.
>From Alan M.:
[19:14] < alanm> bje, use of an uninitialised pseudo in catch blocks
[19:14] < pinskia> alanm: I had that problem before (int a = a; was my issue)
[19:15] < alanm> i
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-01-20 23:56 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01424.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-20 23:49 ---
I am testing the patch that RTH suggested on x86_64-linux-gnu to make sure that
it works there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
--- Comment #1 from amodra at bigpond dot net dot au 2006-01-20 22:51
---
Author: amodra
Date: Fri Jan 20 00:42:29 2006
New Revision: 110004
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110004
Log:
* libgcc2.c (__floatdisf, __floatdidf): Don't use IBM Extended
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-01-20 22:37
---
RTH's comments are here:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01390.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 21:51 ---
Confirmed, related to PR 25091.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Bu
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 21:51 ---
Confirmed, this is obviously wrong as there is no way for different entries to
have different return types.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from danglin at gcc dot gnu dot org 2006-01-20 21:44 ---
I accidently deleted the file.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
mkinstalldirs='/usr/local/bin/bash ../../gcc/gcc/../mkinstalldirs' \
/usr/local/bin/bash mklibgcc > tmp-libgcc.mk
mv tmp-libgcc.mk libgcc.mk
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET USE_COLLECT2" \
/usr/local/bin/bash ../../gcc/gcc/mkconfig.sh tconfig.h
ma
--- Comment #9 from jsm28 at gcc dot gnu dot org 2006-01-20 21:00 ---
Subject: Bug 25524
Author: jsm28
Date: Fri Jan 20 21:00:52 2006
New Revision: 110038
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110038
Log:
PR libstdc++/25524
* gcc/cppdefault.h (struct def
--- Comment #8 from jsm28 at gcc dot gnu dot org 2006-01-20 21:00 ---
Subject: Bug 25524
Author: jsm28
Date: Fri Jan 20 21:00:03 2006
New Revision: 110037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110037
Log:
PR libstdc++/25524
* cppdefault.h (struct default
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 20:56 ---
I am going to declare this is GMP bug as I can reproduce it on two out of three
of my machines. The one with the newest GMP, it works. These three machines
are all different targets, powerpc, x86 and x86-64.
So cl
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 20:51 ---
*** Bug 23631 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 20:51 ---
PR 23477 was fixed in 4.1.0 and not 4.0.3. This is still a dup of that bug.
*** This bug has been marked as a duplicate of 23477 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 20:46 ---
Worked around so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-20 20:45 ---
*** Bug 25887 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 20:45 ---
*** This bug has been marked as a duplicate of 25869 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I can't get GCC trunk to compile on mingw32. The build dies with the following
segfault:
/home/coudert/ibin/./gcc/xgcc -B/home/coudert/ibin/./gcc/
-B/mingw/i686-pc-mingw32/bin/ -B/mingw/i686-pc-mingw32/lib/ -isystem
/mingw/i686-pc-mingw32/include -isystem /mingw/i686-pc-mingw32/sys-include -O2
-I.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 20:43 ---
Confirmed, I thought I had saw another bug about this but no luck, anyways
confirmed.
Hmm, using unsigned short on 32bit targets cause the same issue:
void vector_add(unsigned short n,
double * __re
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-20 20:37
---
(In reply to comment #15)
> Any chance of getting the fix into 4.1?
Yes if someone approves the patch. Which was posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00785.html
I don't know enough of this code
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-01-20 20:14
---
> Confirmed on 4.0.2, also present in 4.1 and 4.2
>
> $ gcc -c -O2 gnatpp-comments.adb
> +===GNAT BUG DETECTED==+
> | 4.1.0 20060112 (prerelease) (x86_64-unknow
--- Comment #3 from laurent at guerby dot net 2006-01-20 20:01 ---
Note this works on i686 with 4.0.2.
Confirmed on 4.0.2, also present in 4.1 and 4.2
$ gcc -c -O2 gnatpp-comments.adb
+===GNAT BUG DETECTED==+
| 4.1.0 20060112 (prerele
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|bonzini at gnu dot org |unassigned at gcc dot gnu
||dot
--- Comment #15 from bonzini at gnu dot org 2006-01-20 19:58 ---
libgomp should use GCC_HEADER_STDINT too. See the patch for PR25884 which does
so.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from bonzini at gnu dot org 2006-01-20 19:56 ---
Created an attachment (id=10692)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10692&action=view)
prototype patch
This is a prototype patch to fix the bug using autoconf to compute the
necessary sizes/alignments
Note
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 19:26 ---
Caused by:
2006-01-19 Diego Novillo <[EMAIL PROTECTED]>
* tree.def (BLOCK): Remove documentation about BLOCK_TYPE_TAGS.
(OMP_PARALLEL): Add 3 operands.
(OMP_SECTIONS): Add 1 operand.
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-01-20 19:17
---
Reduced testcase:
int foo();
struct wigner_d
{
void recurse () {
int dd;
for (int j=0; j<=1; ++j) {
#pragma omp parallel
dd=5;
}
}
};
template void rotate_alm(T arg)
{
wig
Objective-C++ uses 256 tree codes and yes it uses all of them.
So Objective-C++ fails.
--
Summary: almost to 256 tree codes for Objective-C++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
--- Comment #2 from krischik at users dot sourceforge dot net 2006-01-20
19:07 ---
Almost forgot, you want a gcc -v
>gcc -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-suse-linux
Konfiguriert mit: ../gcc-4.0.2/configure --with-gcc --with-gnu-ld --with-
--- Comment #1 from krischik at users dot sourceforge dot net 2006-01-20
19:04 ---
Created an attachment (id=10691)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10691&action=view)
The GNAT chop as whiched
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
Hello
Trying to compile gnatpp I get the a "GNAT BUG DETECTED" box which I like to
share with you all:
gnatmake "-Ptools/gnatpp/gnatpp" "-XBLD=prod" "-XOPSYS=default_Unix"
gcc -c -gnatf -gnatwu -gnaty -O2 -I- -gnatA
/work/martin/asis/tools/gnatpp/gnatpp-comments.adb
+===G
--- Comment #14 from uweigand at gcc dot gnu dot org 2006-01-20 18:39
---
Some additional details about the s390x failure. This is caused by a
miscompile of the fdd2a00__write__2 support routine:
lg %r4,168(%r15) # 35*movdi_64/8 [length = 6]
lg %r3,
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-01-20 18:30 ---
Subject: Re: [4.2 Regression] ice with -g -O2
-fPIC
On Fri, 2006-01-20 at 17:03 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 17:03
>
--- Comment #1 from sje at gcc dot gnu dot org 2006-01-20 18:29 ---
Subject: Bug 24962
Author: sje
Date: Fri Jan 20 18:29:44 2006
New Revision: 110034
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110034
Log:
PR testsuite/24962
* gcc.target/ia64/20030811-1.c: Ch
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-20 18:19 ---
This appears fixed by r110130.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25882
--- Comment #2 from sje at gcc dot gnu dot org 2006-01-20 18:17 ---
Subject: Bug 25877
Author: sje
Date: Fri Jan 20 18:17:28 2006
New Revision: 110031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110031
Log:
PR libgomp/25877
* team.c: Add include of alloca.h.
Like all other target libraries, libgomp should not require perl to compile.
This is either a documention failure as the docs say perl is not required or
this is a bug in libgomp for requiring perl.
--
Summary: libgomp should not require perl to compile
Product: gcc
libgomp (like all other target libraries in GCC) should not be calling pthread
functions directly but instead using the gthr-* files in gcc.
This makes libgomp more portable.
--
Summary: libgomp call pthread functions directly
Product: gcc
Version: 4.2.0
--- Comment #38 from mark at codesourcery dot com 2006-01-20 18:02 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
> Hmpf. One more difficulty. x86
--- Comment #2 from jb at gcc dot gnu dot org 2006-01-20 17:57 ---
Confirmed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-20 17:38 ---
*** Bug 25882 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 17:38 ---
*** This bug has been marked as a duplicate of 25869 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
/home/dave/gnu/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.2.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sy
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
GCC build triplet|x86_64-unknown-linux-gnu|
GCC h
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2006-01-20
17:21 ---
Subject: Re: make clean fails
aoliva at gcc dot gnu dot org wrote:
>--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-20 17:16 ---
>If you mean make -k for sub-makes, yes. But `make cl
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-20 17:16 ---
If you mean make -k for sub-makes, yes. But `make clean && make && make check'
ought to work, and not stop after make clean because it looks like it failed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25790
void vector_add(int n,
double * __restrict__ r,
double * __restrict__ a,
double * __restrict__ b) {
int i;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=25881
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 17:03 ---
This patch worked though:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 110017)
+++ tree-ssa-pre.c (working copy)
@@ -1159,7 +1159,7
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-20 16:42
---
Changing GVN PRE for adding decl as references is harder than I thought. :(.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
--- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
to further fiddle with alignments of fields. On x86 this is used to
adjust the alignment of long long to 4 (instead of the natural 8).
This is used only when
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 16:14 ---
(In reply to comment #6)
> This one is actually not a trivial problem to fix ATM (in this case,
> eliminate would need to be changed as well), so it would be best to just
> change the can_PRE_operation to have someth
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 15:57 ---
Patch which might help:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00881.html
It is not a complete patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-20 16:04 ---
Patches should go to [EMAIL PROTECTED]
The correct quoting style is "%" as %< and %> gets translated to the
corect quote for the person.
You might just say all the Quals which are discarded, there are only 3,
re
--- Comment #1 from roland dot illig at gmx dot de 2006-01-20 15:59 ---
Created an attachment (id=10690)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10690&action=view)
Special warning for ``const''.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
The current gcc warning for discarded qualifiers cannot be easily understood by
beginners:
$ cat const.c
int main(void)
{
const char *pcc;
char *pc;
pcc = "hello, world";
pc = pcc;
return 0;
}
$ gcc -Wall -W const.c
const.c: In function `main':
const.c:7:
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 15:55 ---
The other thing which might help here is trying to find more functions which
can have nothrow on them which should help compile time. I had a patch which
did this at the tree level but never finished it.
--
htt
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-20 15:53 ---
And we can hope that the SSA inliner will do better on the temporaries, but I
guess the resulting CFG will be unchanged. Penaltizing try/finally in
estimate_num_insn_1 instead of declaring them "/* Containers have n
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-20 15:52 ---
(In reply to comment #4)
> I'm going to experiment with moving where the subreg lowering code occurs and
> moving up the splitting into subregs and see if I can get the desired
> results.
> I'm pretty new to GCC, s
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-20 15:50 ---
At .ssa we have for the posted fragment the following loads of basic blocks
and exception objects:
:
D.68636_176 = &this_1->iso639_1;
D.68641_177 = operator[] (D.68636_176, &D.68639);
:
this_230 = (struct
bas
1 - 100 of 134 matches
Mail list logo
