--- Comment #4 from aldot at gcc dot gnu dot org 2008-04-17 11:13 ---
Sounds a little bit like PR6142 popped up again via IRA.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
--- Comment #7 from aldot at gcc dot gnu dot org 2008-04-17 11:32 ---
Changing the attached testcase to use either =q or =R makes no difference, it
still tries to emit the wrong thing, thus reopening.
--
aldot at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from aldot at gcc dot gnu dot org 2008-04-17 12:03 ---
*** Bug 35963 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
--- Comment #8 from aldot at gcc dot gnu dot org 2008-04-17 12:03 ---
fixing the constraint and all is well. Thanks, Andrew!
*** This bug has been marked as a duplicate of 35102 ***
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from aldot at gcc dot gnu dot org 2008-02-21 16:44 ---
-frtl-abstract-sequences should IMHO be turned on per default for at least -Os
in 4.4
Otherwise literally nobody will notice if it's broken.
thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
--- Comment #6 from aldot at gcc dot gnu dot org 2008-02-02 13:43 ---
Created an attachment (id=15077)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15077action=view)
Emit warning for surplus case labels in a switch stmt with a boolean condition
The attached patchlet would warn
--- Comment #7 from aldot at gcc dot gnu dot org 2008-02-02 13:44 ---
Reconfirm for 4.3.0 / 4.4.x
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aldot at gcc dot gnu dot org 2008-02-02 13:46 ---
Add link to PR17843 -- Warning not given for unreachable code in a switch
In this case a boolean condition; Does not use (the already a bit convoluted)
VRP.
--
aldot at gcc dot gnu dot org changed
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-31 15:05 ---
Works with gcc-4.1.2 (if one prunes the 'static' of the weakref; They were
required to be public back then):
$ gcc-4.1 pr35034-1.c pr35034-2.c -O0 -S -o - -combine -pipe
.file pr35034-1.c
.text
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-31 14:47 ---
Smaller testcase:
---
$ cat pr35034-1.c
/* PR 35034 - fails to mangle function names for different TUs. */
/* { dg-do compile } */
/* { dg-options -combine -O0 } */
/* { dg-additional
--- Comment #9 from aldot at gcc dot gnu dot org 2008-01-31 15:18 ---
(In reply to comment #7)
Fails with 4.1.2 for me as well, with the static. w/o 4.1 complains
t1.c:5: error: '__gthrw_pthread_once' defined both normally and as an alias
Works flawlessly for me (without
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-31 15:11 ---
(In reply to comment #2)
I suppose the static function
static const unsigned char *
read_uleb128 (const unsigned char *p, _uleb128_t *val)
{
in unwind-pe.h should be marked 'inline', otherwise
: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-30 22:56 ---
Works with -O2, fails with -O0, -O1, -O2 -fno-inline
-O0:
$ /scratch/obj.i686/gcc-4.3/./gcc/xgcc -B/scratch/obj.i686/gcc-4.3/./gcc/
-B/opt/i686/gcc-4.3//i686-linux-gnu/bin/
-B/opt/i686/gcc-4.3//i686-linux-gnu/lib
--- Comment #10 from aldot at gcc dot gnu dot org 2008-01-29 12:27 ---
Created an attachment (id=15046)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15046action=view)
updated patch for libgcc
Fixes an error about {mul,div}{d,x,t}c3 which wants to be built for different
modes
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-29 15:58 ---
Fixed.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-29 15:57 ---
Subject: Bug 35002
Author: aldot
Date: Tue Jan 29 15:56:20 2008
New Revision: 131940
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131940
Log:
2008-01-29 Bernhard Fischer [EMAIL PROTECTED]
PR c
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-29 16:05 ---
You can pass any *.[fF][9]*[05]* and .inc into this script, it will happily
scan for any un-cleaned mod. See top of the script for the files i initially
fed to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #22 from aldot at gcc dot gnu dot org 2008-01-29 12:33 ---
Michael,
You are right, sorry :(. I somehow managed not to find them although they are
there!
---8---
# Dummy rules to deal with dependencies produced by use of
# [EMAIL PROTECTED]@ and [EMAIL PROTECTED]@ above
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35015
--- Comment #9 from aldot at gcc dot gnu dot org 2008-01-29 21:07 ---
Created an attachment (id=15053)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15053action=view)
patch in testing
This is a simple fix to adjust the respective vector (that get's
filled/finalized far too early
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-29 20:35 ---
Several question marks for someone more familiar with the testsuite..
In the event that we can check against several multilib variants (?) that thus
match different dg-require (?), we may (?) eventually check against
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-28 17:30 ---
Invalid code should be diagnosed. Since this particular case even has a flag to
accept the invalid code, the hard error is fine IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34997
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-28 16:34 ---
See also
http://gcc.gnu.org/ml/fortran/2007-01/msg00060.html
specifically the PS ... -fdollar-ok there.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from aldot at gcc dot gnu dot org 2008-01-28 17:59 ---
Created an attachment (id=15038)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15038action=view)
use conditional $(BUILD_INFO) variable for prerequs of info and install-info
targets
Use the variable
--- Comment #20 from aldot at gcc dot gnu dot org 2008-01-28 20:43 ---
(In reply to comment #19)
In your patch, why does install-info still need doc and installdirs
dependencies when BUILD_INFO is not set? If those things still need to
happen,
shouldn't they be dependencies
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-28 21:47 ---
Confirmed.
Also wrong:
gcc/ipa-struct-reorg.c:sum_counts (d_str str, gcov_type *hotest)
gcc/ipa-struct-reorg.c: if (str-count *hotest)
gcc/ipa-struct-reorg.c:*hotest = str-count;
gcc/ipa-struct-reorg.c
--- Comment #6 from aldot at gcc dot gnu dot org 2008-01-27 13:36 ---
$ for i in 2.95 3.3 3.4 4.1 4.3.orig-HEAD 4.3-HEAD;do echo # GCC $(gcc-$i
--version | sed 1q);gcc-$i -Os -c -o pr.o.gcc-$i pr23782.c;done
# GCC 2.95.4
pr23782.c:8: warning: `fastcall' attribute directive ignored
# GCC
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-27 17:24 ---
Created an attachment (id=15028)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15028action=view)
file 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-27 17:24 ---
Created an attachment (id=15029)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15029action=view)
file2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34989
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-27 17:26 ---
Works fine with
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
And did work with trunk until recently (at least end of december, IIRC)
--
aldot at gcc dot gnu dot org changed:
What
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-27 18:10 ---
original and reduced testcases work with 4.2:
$ gcc-4.2 -O2 -c -o bazoo.o one.i two.i -combine ; echo $?
0
$ gcc-4.2 -O2 -c -o bazoo.o syslogd.i xregcomp.i -combine ; echo $?
0
$ gcc-4.2 --version | sed 1q
gcc-4.2
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-27 18:35 ---
right.. thus closing.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-25 08:28 ---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-25 18:02 ---
Mine.
$ cat pr31537.i
static int __gthrw_pthread_once __attribute__ ((__weakref__ (pthread_once)));
$ gcc-4.3-HEAD -S -o - -Os pr31537.i pr31537.i pr31537.i \
pr31537.i pr31537.i pr31537.i -fno-tree-vnhoist -combine
--- Comment #16 from aldot at gcc dot gnu dot org 2008-01-25 15:24 ---
Removing alphaev56-dec-osf5.1a since this is not target specific.
The treelang-noinfo.patch looks fine to me, but i cannot approve it (mark?).
--
aldot at gcc dot gnu dot org changed:
What
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-24 13:43 ---
Created an attachment (id=15016)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15016action=view)
updated patch
tiny fix: libgcc-s-objects-onestep is only needed for enable_shared=yes.
Two other buglets fixed
--- Comment #9 from aldot at gcc dot gnu dot org 2008-01-24 16:15 ---
Stats:
-rw-r--r-- 1 1000 1000 3853392 Jan 24 13:28
./build_i686/gcc-4.3.0-target.IMA/i686-linux-uclibc/libgcc/libgcc.a
2826503 34784 8 2861295 2ba8ef (TOTALS)
-rw-r--r-- 1 1000 1000 4569970 Jan 24 14:00
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-23 10:43 ---
I've fixed superH locally via
\\ gcc PR33200
Index: gcc-4.3.0/gcc/config.gcc
===
--- gcc-4.3.0/gcc/config.gcc(revision 131628)
+++ gcc-4.3.0
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-23 14:41 ---
Created an attachment (id=15008)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15008action=view)
libgcc patch #2
Updated patch
--
aldot at gcc dot gnu dot org changed:
What|Removed
dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34922
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-22 14:03 ---
If disabling toplevel directories is really generic, then libada and libssp
should be removed from the --help output.
--enable-languages=c --disable-libstdc++-v3
should be accepted.
Means to use a different libstdc
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-22 18:04 ---
You should document this (awkward) flag in the --help output, though.
Still, it is inconsistent to mention just a few of the possible arguments in
the help text, thus my question:
Should all toplevel libdirs
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-19 12:37 ---
Bruce,
Can you please have a look. How is that ment to work?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-19 14:14 ---
Assuming build=i386-linux-*, host==target==sh4-linux-*, i.e. cross-compiling a
native compiler for SuperH:
-) sh*-* forces use_fixproto in config.gcc (why?)
See config.gcc: line 2308
-) stmp-install-fixproto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
GCC build triplet: i686-linux-uclibc
GCC host triplet: i386-linux-gnu
GCC target triplet: i686-linux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34873
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-19 21:38 ---
From FSFChangelog.10:
Mon Feb 12 20:42:11 1996 Randy Smith [EMAIL PROTECTED]
* i386/x-osfrose (XCFLAGS{,_NODEBUG}): Remove $(SHLIB).
(XCFLAGS): New variable.
(libdir, mandir, bindir): Delete
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-18 18:06 ---
Confirmed.
# Install supporting files for fixincludes to be run later.
install-mkheaders: stmp-int-hdrs $(STMP_FIXPROTO) install-itoolsdirs \
macro_list fixinc_list
[snip]
if [ x$(STMP_FIXPROTO) != x
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-18 18:38 ---
fix-proto is never run, it seems:
$ grep stmp- out.log
echo timestamp stmp-fixinc
echo timestamp stmp-int-hdrs
echo timestamp stmp-install-fixproto
if [ xstmp-install-fixproto != x ] ; then \
after
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-18 01:39 ---
Works with the 4.2.2 release.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
: aldot at gcc dot gnu dot org
GCC build triplet: i386-linux-gnu
GCC host triplet: sh4-linux-uclibcgnueabi
GCC target triplet: sh4-linux-uclibcgnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-16 13:21 ---
Created an attachment (id=14948)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14948action=view)
slightly reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-15 10:10 ---
This was recently changed on trunk:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01574.html
via
r127745 | drow | 2007-08-23 19:42:08 +0200 (Thu, 23 Aug 2007) | 4 lines
* configure.ac (leb128): Modify sed
--- Comment #10 from aldot at gcc dot gnu dot org 2008-01-11 13:30 ---
Still fails for me on trunk (revision 131461):
gcc-4.3-HEAD -Os --combine -c -o pr28779.o pr28779a.c pr28779b.c
pr28779b.c: In function 'e1000_write_reg_io':
pr28779b.c:12: internal compiler error
--- Comment #12 from aldot at gcc dot gnu dot org 2008-01-11 15:21 ---
Honza, the IPA pass reordering also caused PR31529, perhaps they are related?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-04 09:15 ---
I'd say that this is blocked by PR18624 (resp. PR30438 for fortran).
dcb, you seem to report these as separate PRs. Previous of this category
include:
PR25547
PR25567
PR26245
PR32948
--
aldot at gcc dot gnu dot
--- Comment #2 from aldot at gcc dot gnu dot org 2008-01-04 12:51 ---
Created an attachment (id=14875)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14875action=view)
optabs.i
file1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-04 12:50 ---
Works with:
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Fails with 4.3.0 since at least
gcc version 4.3.0 20071212 (experimental) (GCC)
Starting program: /opt/i686/gcc-4.3/lib/gcc/i686-linux-gnu/4.3.0
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-04 12:51 ---
Created an attachment (id=14876)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14876action=view)
arm.i (file2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-04 13:06 ---
Works with
gcc-4.3.orig-HEAD (GCC) 4.3.0 20070919 (experimental)
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from aldot at gcc dot gnu dot org 2008-01-04 13:52 ---
Smaller testcase:
cat arm.i -EOF
struct optab { unsigned code; };
extern struct optab optab_table[1];
EOF
cat optabs.i -EOF
struct optab { unsigned code; };
extern struct optab optab_table[1];
void
init_optab
--- Comment #6 from aldot at gcc dot gnu dot org 2008-01-03 09:19 ---
Dummy sample that has a hoisting opportunity:
int bazoo (unsigned int in)
{
int i = 0;
if (in = 0)
++i; /* hoist */
if (in = 1)
++i;
if (in = 2)
++i;
if (in = 3)
++i;
if (in = 4)
++i
--- Comment #6 from aldot at gcc dot gnu dot org 2008-01-02 19:06 ---
Any update?
Current trunk still produces wrong code for weakrefs..
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from aldot at gcc dot gnu dot org 2007-12-30 10:47 ---
Created an attachment (id=14842)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14842action=view)
rough, half-finished, disfunctional thought; not a patch
The attached thoughts do not yet insert/remove stmt
--- Comment #6 from aldot at gcc dot gnu dot org 2007-12-15 12:49 ---
(In reply to comment #4)
None of these works:
find . -type l -or -type d -print
find . -type l OR -type d -print
find . -type l or -type d -print
In current busybox (IIRC = 1.6) these are available if you
--- Comment #9 from aldot at gcc dot gnu dot org 2007-12-15 14:44 ---
Is suggest you get a current busybox-1.8.2 and just turn on the applets you
need, including DESKTOP support for find (which is a required feature according
to SUSv3, as steven mentioned).
With everything turned
--- Comment #8 from aldot at gcc dot gnu dot org 2007-12-15 17:23 ---
Two disfunctional testcases:
pr31529_1a.i:
extern getline(){}
pr31529_1b.i:
extern getline(){}
pr31529_2a.i:
extern getline(){}
pr31529_2a.i:
extern __inline getline(){}
Trying to fix this in cfg led
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: hjl at lucon dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.2.2
Summary|pulls in allegedly unneeded |[4.3 Regression
--- Comment #11 from aldot at gcc dot gnu dot org 2007-12-15 17:55 ---
Using programs that are required by SUSv3 in their complete feature set is
fine.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aldot at gcc dot gnu dot org 2007-12-15 20:15 ---
IIRC i initially experienced this not on i386 but with mips or arm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
--- Comment #4 from aldot at gcc dot gnu dot org 2007-12-14 09:11 ---
Abovementioned C PR is PR18624 .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438
--- Comment #2 from aldot at gcc dot gnu dot org 2007-12-14 11:05 ---
Confirmed. gcc-2.95.4 works as expected:
$ gcc-2.95 -Os -fomit-frame-pointer pr29978.i -S -o -
.file pr29978.i
.version01.01
gcc2_compiled.:
.text
.align 16
.globl f
.type
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29978
--- Comment #6 from aldot at gcc dot gnu dot org 2007-12-14 15:00 ---
Still present on current trunk (20071214).
This used to work with 3.4.6:
.L14:
cmpl$5, %eax
ja .L14
.ident GCC: (GNU) 3.4.6 (Debian 3.4.6-6)
Not quite optimal though since this would
--- Comment #4 from aldot at gcc dot gnu dot org 2007-12-13 22:06 ---
Is this realted to PR30354 and/or PR28417 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34452
--- Comment #14 from aldot at gcc dot gnu dot org 2007-12-11 08:46 ---
(In reply to comment #13)
Just asking for status of this bug:
Seems to be still valid with gcc-4.2.2 - don't (want to) have texinfo
installed.
Please submit a tested patch along the lines of Mark's comment #8
--- Comment #1 from aldot at gcc dot gnu dot org 2007-12-07 10:33 ---
*** This bug has been marked as a duplicate of 34359 ***
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aldot at gcc dot gnu dot org 2007-12-07 10:33 ---
*** Bug 34377 has been marked as a duplicate of this bug. ***
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from aldot at gcc dot gnu dot org 2007-12-05 22:48 ---
Sounds like this was introduced by the ipa pass reordering in r120527 ff.
Jakub, can you confirm this?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from aldot at gcc dot gnu dot org 2007-12-04 12:28 ---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
--- Comment #5 from aldot at gcc dot gnu dot org 2007-12-02 19:35 ---
Works:
$ cat one.i
extern getline();
$ gcc-4.2 -c -o pr.o one.i one.i -combine -fdump-tree-all
$ gcc-4.3-HEAD -c -o pr.o one.i one.i -combine -fdump-tree-all
4.3 doesn't seem to see the body?
$ cat one.i
extern
--- Comment #4 from aldot at gcc dot gnu dot org 2007-11-30 16:59 ---
Breakpoint 2, cgraph_expand_function (node=0xb7c7a280)
at ../../../src/gcc-4.3/gcc/cgraphunit.c:1138
1138 tree decl = node-decl;
1141 gcc_assert (!node-global.inlined_to);
1143
--- Comment #3 from aldot at gcc dot gnu dot org 2007-11-30 16:53 ---
Target independent. Reduced from toplev.c and i386.c:
$ cat one.i
getline ()
{
}
$ cat two.i
extern __inline
getline ()
{
}
$ /scratch/obj.i686/gcc-4.3/./prev-gcc/xgcc -v
-B/scratch/obj.i686/gcc-4.3/./prev-gcc/
-B
--- Comment #2 from aldot at gcc dot gnu dot org 2007-11-29 13:27 ---
Can you please provide a testcase for the testsuite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
--- Comment #9 from aldot at gcc dot gnu dot org 2007-11-28 14:47 ---
If the requested bitfield is larger than the type that was previously tried for
enum, then you have to widen the type to fulfill that constaint.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
--- Comment #2 from aldot at gcc dot gnu dot org 2007-11-28 16:28 ---
Can still be observed on trunk.
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
--- Comment #11 from aldot at gcc dot gnu dot org 2007-11-28 17:44 ---
The standard (6.7.2.2, 4) talks about the note in #7.
I read this as for this input:
8---
enum e {ee};
struct s { __extension__ enum e baz:16; };
8---
The smallest type that can represent
--- Comment #12 from aldot at gcc dot gnu dot org 2007-11-28 18:28 ---
Not target specific, adjusting accordingly.
Observed everywhere with -fshort-enums
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from aldot at gcc dot gnu dot org 2007-11-28 20:50 ---
A toplevel 'make' does what 'make bubblestrap' did before.
See also:
http://gcc.gnu.org/ml/gcc/2005-12/msg00435.html
http://gcc.gnu.org/ml/fortran/2005-12/msg00338.html
If install.texi from the 4_2-branch mentions
--- Comment #6 from aldot at gcc dot gnu dot org 2007-11-27 19:48 ---
I ment to build with arch=tune=abi for iwmmxt
As you say, arm.c suggests that iwmmxt defaults to -fshort-enums here, fwiw:
/* AAPCS based ABIs use short enums by default. */
static bool
arm_default_short_enums
--- Comment #7 from aldot at gcc dot gnu dot org 2007-11-27 20:15 ---
s/int//. The enumerated type is implementation defined but shall be capable to
represent the values of all members.
I'd read this as -fshort-enum violating that :16?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from aldot at gcc dot gnu dot org 2007-11-26 17:09 ---
I don't see an explicit -fshort-enums in my flags..
I'm using this:
CFLAGS_FOR_TARGET=-Os -pipe -fno-tree-loop-optimize -fno-tree-dominator-opts
-fno-strength-reduce -fno-branch-count-reg
-I/there/build_armeb
--- Comment #4 from aldot at gcc dot gnu dot org 2007-11-26 17:11 ---
While the configure explicitely lists armeb, the very same thing happens for
arm(el), fwiw.
Does perhaps one of -m{arch,abi}=iwmmxt imply -fshort-enums ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
--- Comment #3 from aldot at gcc dot gnu dot org 2007-11-23 12:24 ---
Please backport to the 4_2-branch, too. Looks like this was only applied to
trunk.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
GCC build triplet: armeb-linux-*gnueabi
GCC host triplet: i386-linux-gnu
GCC target triplet: armeb-linux-*gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
--- Comment #1 from aldot at gcc dot gnu dot org 2007-11-23 10:59 ---
Created an attachment (id=14625)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14625action=view)
reduced from gcc/tree.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
Severity: minor
Priority: P3
Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34120
101 - 200 of 373 matches
Mail list logo
