http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54166
--- Comment #5 from koen.poppe at cs dot kuleuven.be 2012-08-06 06:53:56 UTC ---
You're welcome! Thank you for the quick fix!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170
bekenn at yopmail dot com changed:
What|Removed |Added
Attachment #27935|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170
--- Comment #5 from bekenn at yopmail dot com 2012-08-06 04:44:17 UTC ---
Created attachment 27948
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27948
Full application showing issue.
Sorry for the wait. Here is a complete program showing th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
Bug #: 54185
Summary: condition_variable not properly destructed
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53534
--- Comment #2 from Matthew Busche 2012-08-06
04:18:56 UTC ---
Andrew,
I spent quite a bit of time tracking down this bug, coming up with a simple
test case that produces the problem, and writing up the bug report. Is it
normal for bugs to go i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Chip Salzenberg changed:
What|Removed |Added
CC||chip at pobox dot com
--- Comment #42 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
--- Comment #16 from Chip Salzenberg 2012-08-06
00:57:13 UTC ---
Addendum: In cut down test cases where I only pass by value or only return by
value, but not both, I find no extra stores, which is good; but I still find a
lot of unnecessary frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
Chip Salzenberg changed:
What|Removed |Added
CC||chip at pobox dot com
--- Comment #15 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184
Bug #: 54184
Summary: [4.8 Regression] gcc.dg/pr52558-1.c failure
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53439
--- Comment #4 from Christophe Prud'homme 2012-08-05 22:37:57 UTC ---
The code I attached to this bug report seems to be fine now. However I have
other instances of these crashes(segfaults) in other codes that I will attach
any time soon.
The diag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54183
Bug #: 54183
Summary: Generate __udivmoddi4 instead of __udivdi3 plus
__umoddi3
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #18 from Steven Bosscher 2012-08-05
21:13:26 UTC ---
Created attachment 27946
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27946
Speed up ifcvt.c:check_cond_move_block
This speeds up the pre-reload if-conversion passes by usin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #27 from Steven Bosscher 2012-08-05
21:05:41 UTC ---
(In reply to comment #26)
> And what has any of this to do with the simple question posed in the title
> of this bug report : why can't insn-emit.c be split ?
It could be split up.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #26 from Jason Vas Dias
2012-08-05 20:57:59 UTC ---
Well, when I read on the documentation page
http://gcc.gnu.org/install/configure.html
--enable-build-with-cxx
Build GCC using a C++ compiler rather than a C compiler. This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Steven Bosscher changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #25 from Steven Bos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #24 from Jason Vas Dias
2012-08-05 20:10:36 UTC ---
$ ps -lp 3863
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 R 0 3863 3862 99 80 0 - 64611 - pts/51-05:55:03 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #23 from Jason Vas Dias
2012-08-05 19:51:56 UTC ---
Yes, I was wondering how long it would take to close this bug as INVALID,
which seems to be the standard response to uncomfortable bug reports these
days.
It turned out to be less
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182
Bug #: 54182
Summary: enable -fvisibility=hidden
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #22 from Jason Vas Dias
2012-08-05 19:48:45 UTC ---
RE:
> If you want a C-only compiler then you should just configure with
> "--enable-languages=c" only
of course, I tried that first, but that is no longer possible with gcc-4.7.1+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54181
Bug #: 54181
Summary: partial DW_TAG_class_type generated with
DW_AT_byte_size and without DW_AT_declaration
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #17 from Steven Bosscher 2012-08-05
18:48:55 UTC ---
(In reply to comment #14)
> if-conversion : 177.26 (but due to loop_optimizer_init)
Hmm, this is not loop_optimizer_init. All time is spent in the two memset calls
in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #9 from vries at gcc dot gnu.org 2012-08-05 18:16:21 UTC ---
test-case for LSHIFT_EXPR vrp:
...
extern void link_error (void);
void
f3 (int s, int b)
{
if (s >> 3 == -2)
/* s in range [-16, -9]. */
{
s += 17;
/*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #20 from Jason Vas Dias
2012-08-05 18:10:24 UTC ---
RE: > --disable-bootstrap if you're doing --enable-gather-statistics
but for me this defeats the whole purpose of building a "C-only"
bootstrap compiler.
I see no point in proceed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883
--- Comment #10 from Daryle Walker 2012-08-05
17:13:08 UTC ---
I've added attachment 27945, a bzip2 archive of the "making1.txt" file. That
file is the "tee" results of the three "make" runs given in comment 7
(http://gcc.gnu.org/bugzilla/show_b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883
--- Comment #9 from Daryle Walker 2012-08-05
17:09:00 UTC ---
Created attachment 27945
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27945
Output from running make, for gcc and tests, with tee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883
--- Comment #8 from Daryle Walker 2012-08-05
16:51:57 UTC ---
I haven't check the results of the testing-make yet, but I tried sending the
results in.
//===
nano your_commentary.txt
../gcc/contrib/test_summary -p your_commentary.txt -m
gcc-testr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #8 from vries at gcc dot gnu.org 2012-08-05 15:31:39 UTC ---
Created attachment 27944
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27944
tree-switch-conversion-fix-undefined-overflow-introduction.patch, tentative
patch
> Anyway,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180
--- Comment #4 from Denis Kolesnik 2012-08-05
15:12:58 UTC ---
Created attachment 27943
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27943
asm file as addition to the source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180
--- Comment #2 from Denis Kolesnik 2012-08-05
15:10:47 UTC ---
Created attachment 27942
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27942
object file to source
all files modified in an text editor to change password - so it size may vary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180
--- Comment #1 from Denis Kolesnik 2012-08-05
15:08:35 UTC ---
Created attachment 27941
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27941
additional files to source asked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180
Bug #: 54180
Summary: a bug using strcat function - it depends on variable
declare order, but it should not.
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #18 from wbrana 2012-08-05 14:11:37 UTC
---
(In reply to comment #17)
> Sorry, but this is just rubbish.
You didn't confute my statements.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #17 from Steven Bosscher 2012-08-05
13:55:43 UTC ---
(In reply to comment #12)
> Average user doesn't build or use compiler. It is only done by developers
> which
> have modern PC which means 8 GB RAM.
Sorry, but this is just rubbis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #16 from Steven Bosscher 2012-08-05
13:54:30 UTC ---
> $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 \
> --enable-multilib --with-cpu-32=i686 --with-cpu-64=k8 \
> --enable-version-specific-runtime-libs \
> --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #7 from stevenb.gcc at gmail dot com
2012-08-05 13:53:30 UTC ---
On Sun, Aug 5, 2012 at 3:32 PM, vries at gcc dot gnu.org
wrote:
> I think you forgot the cast to unsigned after the add that represents the
> currently generated code:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #15 from Jason Vas Dias
2012-08-05 13:51:27 UTC ---
Created attachment 27939
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27939
pre-processed "C" from previous comment command
$ xz --uncompress < insn-emit.i.xz > insn-emit.i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #14 from Jason Vas Dias
2012-08-05 13:46:26 UTC ---
$ time /mnt/sda3/gcc/./prev-gcc/xgcc -B/mnt/sda3/gcc/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/bin/
-B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #13 from Jason Vas Dias
2012-08-05 13:43:21 UTC ---
RE: > Steven Bosscher 2012-08-05 12:37:28 UTC \
(In reply to comment #7)
>> These memory requirements are solely due to the size of the .c file (1.8MB) .
>
> This is indeed excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #6 from vries at gcc dot gnu.org 2012-08-05 13:32:15 UTC ---
> s_1 (u)s_1 s_1+16 ((u)s_1)+16 T T
> -16 4294967280 0 00 0
> -12 4294967284 4 40
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #12 from wbrana 2012-08-05 13:31:28 UTC
---
embedded systems compiler doesn't mean you can run gcc on embedded system, but
you can cross compile for embedded system.
Average user doesn't build or use compiler. It is only done by devel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #11 from Jason Vas Dias
2012-08-05 13:16:03 UTC ---
Thanks for the responses - I will try again with
'--enable-checking=release'.
But, I still don't think this bug is a "non-issue" - here's why:
RE: wbrana 2012-08-05 12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #10 from Steven Bosscher 2012-08-05
12:37:28 UTC ---
(In reply to comment #7)
> These memory requirements are solely due to the size of the .c file (1.8MB) .
This is indeed excessive, we'll have to look into this. If you have
preproc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #9 from Steven Bosscher 2012-08-05
12:33:56 UTC ---
(In reply to comment #7)
> cc1 is writing about one line every 2 minutes to its assembler output file:
If you've really configured with --enable-stage1-checking=all, you've enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #8 from wbrana 2012-08-05 12:27:52 UTC ---
2 GB RAM isn't enough.
It isn't good idea to use x86_64 with 2 GB RAM.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #7 from Jason Vas Dias 2012-08-05
12:21:10 UTC ---
Thanks for your response !
I think the cc1 process is somehow operating in slow motion,
even though I've pinned the CPU frequency to 1.8 GHz (it
will crash if I don't reduce it soon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #5 from wbrana 2012-08-05 12:00:50 UTC ---
(In reply to comment #3)
> And what type of super-computer is that ?
outdated, almost 5 years old: Core 2 Quad 3.2 GHz, 4 GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #4 from Jason Vas Dias 2012-08-05
11:43:03 UTC ---
in case the configuration is relevant:
It was created by configure, which was
generated by GNU Autoconf 2.64. Invocation command line was
$ /usr/build2/gcc/gcc-4.7.1/configure -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher changed:
What|Removed |Added
Attachment #27917|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #3 from Jason Vas Dias 2012-08-05
11:36:05 UTC ---
RE:
> Your PC is broken.
Comments such as these don't help much.
No, only Linux 3.4+ temperature management is.
I'm working with the Linux developers to resolve this .
Meanwhile, I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #5 from Steven Bosscher 2012-08-05
11:35:40 UTC ---
Just to illustrate:
$ cat t.c
#include
int
main (void)
{
int cases[] = { -16, -12, -9, -17 };
int i, v;
printf ("Show why cast must happen after add. T==1 iff (D.1732_8 != 0)\
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
wbrana changed:
What|Removed |Added
CC||wbrana at gmail dot com
--- Comment #2 from wbra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #1 from Jason Vas Dias 2012-08-05
11:11:28 UTC ---
Why must we compile 1.8MB of insn-emit.c ?
Can't it be split up ?
Why is gcc-4.7.1 SO much slower ?
ie. evidently the Stage1 and Stage2 compilers were able to build insn-emit.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #4 from Steven Bosscher 2012-08-05
11:05:56 UTC ---
(In reply to comment #3)
> I think we should cast to unsigned first, then add.
No, see what happens to "case -12" if you use ((unsigned)s_1+16).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Bug #: 54179
Summary: please split insn-emit.c !
Classification: Unclassified
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077
--- Comment #11 from wbrana 2012-08-05 10:56:58 UTC
---
I found something strange. There is much smaller slow down in ASSIGNMENT
without 175752 with Gentoo Hardened patches
gcc version 4.7.2 20120804 (prerelease) (Gentoo Hardened 4.7.2 p1.2, pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54174
Richard Guenther changed:
What|Removed |Added
Keywords||ra
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54178
Bug #: 54178
Summary: qualifying a record aggregate incorrectly hides names
in local instantiation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53615
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ice-checking
Status|WAITIN
64 matches
Mail list logo