: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux
--- Comment #2 from edwintorok at gmail dot com 2009-01-15 09:50 ---
(In reply to comment #1)
This is the frame-pointer setup code. You can get the same code as x86_64
with
-momit-leaf-frame-pointer.
Ok. But can't the optimizers see that you push ebp, write something
--- Comment #3 from edwintorok at gmail dot com 2009-01-15 09:51 ---
(In reply to comment #2)
(In reply to comment #1)
This is the frame-pointer setup code. You can get the same code as x86_64
with
-momit-leaf-frame-pointer.
Ok. But can't the optimizers see that you push
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http
--- Comment #1 from edwintorok at gmail dot com 2007-09-29 18:10 ---
Created an attachment (id=14267)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14267action=view)
preprocessed C program to reproduce bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33591
: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34134
--- Comment #1 from edwintorok at gmail dot com 2007-11-17 14:03 ---
Created an attachment (id=14572)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14572action=view)
reduced testcase
To reproduce bug run: gcc -O1 testcase-min.i
I used the delta tool to produce a reduced testcase
--- Comment #2 from edwintorok at gmail dot com 2007-11-17 14:09 ---
(In reply to comment #1)
Created an attachment (id=14572)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14572action=view) [edit]
reduced testcase
To reproduce bug run: gcc -O1 testcase-min.i
I used the delta
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org
--- Comment #3 from edwintorok at gmail dot com 2009-04-12 09:32 ---
(In reply to comment #2)
(In reply to comment #1)
There is no undefined behavior here (increment of a short value converts
to int, increments then converts back to short, none of which are
undefined), so
--- Comment #5 from edwintorok at gmail dot com 2009-04-13 06:56 ---
(In reply to comment #4)
(In reply to comment #3)
But converting from short to int for the argument to printf should behave
as if
a short value was converted to int, i.e. the int value should be in range
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http
--- Comment #1 from edwintorok at gmail dot com 2009-04-25 09:39 ---
Created an attachment (id=17690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17690action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891
: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC
--- Comment #2 from edwintorok at gmail dot com 2009-04-25 13:49 ---
(In reply to comment #1)
Casting through a union (2)
describes an invalid way of doing type-punning.
There is also a citation from C99 on that page:
An object shall have its stored value accessed only by an lvalue
--- Comment #4 from edwintorok at gmail dot com 2009-04-25 14:12 ---
(In reply to comment #3)
The above is properly optimized. Why do you think that an inline
function taking void * would fix anything?
I can't know if memcpy will be inlined, it may just be a function call
--- Comment #7 from edwintorok at gmail dot com 2009-04-25 14:18 ---
(In reply to comment #5)
An object shall have its stored value accessed only by an lvalue
expression
that has one of the following types:
* a type compatible with the effective type of the object
--- Comment #9 from edwintorok at gmail dot com 2009-04-25 14:22 ---
(In reply to comment #6)
No, not if it is inlined (and if not you can as well use memcpy).
You can also do (GCC extension)
union union_t {
unsigned un;
char c[4];
};
unsigned bar(char *x
not throw but has an
EH edge
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot
--- Comment #1 from edwintorok at gmail dot com 2009-10-19 16:55 ---
Created an attachment (id=18827)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18827action=view)
SourceMgr.i
preprocessed SourceMgr.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
--- Comment #2 from edwintorok at gmail dot com 2009-10-19 16:56 ---
Created an attachment (id=18828)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18828action=view)
AsmMatcherEmitter.i.bz2
bzipped preprocessed AsmMatcherEmitter.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from edwintorok at gmail dot com 2009-10-19 16:58 ---
ld -v
GNU gold (GNU Binutils for Debian 2.20) 1.9
This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1,
or not using -use-linker-plugin hides the bug (and not using -flto too of
course
--- Comment #4 from edwintorok at gmail dot com 2009-10-19 16:59 ---
(In reply to comment #3)
ld -v
GNU gold (GNU Binutils for Debian 2.20) 1.9
This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1,
or not using -use-linker-plugin hides the bug
reference (const
with non-const)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail
--- Comment #1 from edwintorok at gmail dot com 2009-10-20 07:05 ---
Created an attachment (id=18830)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18830action=view)
reduced testcase
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
--- Comment #7 from edwintorok at gmail dot com 2009-10-20 15:06 ---
(In reply to comment #6)
Fixed.
Thanks, I can now successfully build ClamAV with lto.
--
edwintorok at gmail dot com changed:
What|Removed |Added
error in gold
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC
--- Comment #1 from edwintorok at gmail dot com 2009-10-21 11:22 ---
Created an attachment (id=18855)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18855action=view)
testcase (reduced not.i)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
--- Comment #1 from edwintorok at gmail dot com 2010-01-05 18:09 ---
(In reply to comment #0)
$ make -j4
This should have been: make CCLD=g++ -j4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
--- Comment #4 from edwintorok at gmail dot com 2010-01-12 07:28 ---
(In reply to comment #3)
Johannes is looking into it,
Thanks.
certainly reproducing the problem will not be a
trivial taks, I'm afraid...
If the steps I listed in the bugreport don't work for you just let me
--- Comment #7 from edwintorok at gmail dot com 2010-01-12 12:41 ---
(In reply to comment #6)
Can I get this thing to run without actually installing it into the system?
5. clamd/clamd -c etc/clamd.conf
LibClamAV Error: cl_load(): Can't get status of /usr/local/share/clamav
ERROR
--- Comment #8 from edwintorok at gmail dot com 2010-01-12 12:51 ---
(In reply to comment #7)
What happens for OMP_NUM_THREADS=1?
Will test now.
It doesn't hang with OMP_NUM_THREADS=1. It does hang with OMP_NUM_THREADS=2,
or with OMP_NUM_THREADS unset.
Please enter the GCC
--- Comment #9 from edwintorok at gmail dot com 2010-01-12 13:35 ---
Could this bug be related to this one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242#c4
Clamd creates threads using pthread_create, std::find is called from those
threads. There are also threads that only poll
--- Comment #13 from edwintorok at gmail dot com 2010-01-12 17:54 ---
(In reply to comment #12)
Thread 1 waits for its colleagues, but where are they gone? Is it possible
that an exception is thrown inside find (by means of the value type or the
predicate)?
I don't fully trust gdb
--- Comment #15 from edwintorok at gmail dot com 2010-01-13 20:39 ---
(In reply to comment #14)
(In reply to comment #13)
This code is compiled with -fno-exceptions, could that be a problem?
No, that should rather help.
Still, it is very difficult to debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
--- Comment #1 from edwintorok at gmail dot com 2008-09-22 20:18 ---
/* testcase compile this with -O1 */
typedef struct TCase TCase;
typedef void (*TFun) (int);
typedef struct Suite Suite;
void _tcase_add_test (TCase * tc, TFun tf, const char *fname, int signal
: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37658
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:20 ---
Created an attachment (id=16415)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16415action=view)
testcase
time gcc-4.3 -O2 testcase.i -c
real2m13.341s
user2m13.008s
sys 0m0.308s
--
http
in class AREG
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:28 ---
Created an attachment (id=16416)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16416action=view)
file dumped by gcc
This is the file dumped by gcc, I am trying to get a reduced testcase using
delta, will attach
--- Comment #2 from edwintorok at gmail dot com 2008-09-27 16:40 ---
Reduced testcase:
/* gcc -fschedule-insns */
int foo(int a, int b) {
return bar(foobar(b) / foobar(a));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
--- Comment #3 from edwintorok at gmail dot com 2008-09-27 16:43 ---
the error message for the above testcase:
$ gcc-4.3 -fschedule-insns v.i
v.i: In function foo:
v.i:3: error: unable to find a register to spill in class AREG
v.i:3: error: this is the insn:
(insn 17 20 18 2 v.i:2
--- Comment #7 from edwintorok at gmail dot com 2008-10-01 16:43 ---
Thanks, gcc4.4 doesn't crash anymore now.
--
edwintorok at gmail dot com changed:
What|Removed |Added
: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
--- Comment #1 from edwintorok at gmail dot com 2008-10-18 13:39 ---
(In reply to comment #0)
Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1.
$ gcc-4.3 -O2 PR1386.c ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly
--- Comment #4 from edwintorok at gmail dot com 2008-10-18 18:07 ---
(In reply to comment #3)
Does it work with -fno-strict-aliasing?
It doesn't.
[EMAIL PROTECTED]:~$ g++ -O2 -fno-strict-aliasing x.c
x.c: In function int main():
x.c:15: warning: large integer implicitly truncated
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org
--- Comment #13 from edwintorok at gmail dot com 2008-10-29 18:48 ---
I just noticed that this testcase also fails with -O3 on gcc version 4.1.2
20070626 (Red Hat 4.1.2-14), but works on gcc version 4.1.3 20080623
(prerelease) (Debian 4.1.2-23)
--
edwintorok at gmail dot com changed
--- Comment #17 from edwintorok at gmail dot com 2008-11-03 17:50 ---
Thanks.
--
edwintorok at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host
--- Comment #1 from edwintorok at gmail dot com 2008-11-06 20:58 ---
/* testcase
gcc -O2 -Wall -c foo.c */
char *get(void);
int use(const char *);
void foo(const char *bar)
{
char *foobar;
if(!bar)
foobar = get();
if(use(bar
--- Comment #2 from edwintorok at gmail dot com 2008-11-06 20:59 ---
/* testcase
* gcc -Wall -O2 -c foo.c
*/
char *get(void);
int use(const char *);
void foo(const char *bar)
{
char *foobar;
if(!bar)
foobar = get();
if(use(bar
--- Comment #3 from edwintorok at gmail dot com 2008-11-06 21:01 ---
Same happens if I use int instead of a pointer:
/* testcase */
/* gcc -O2 -Wall -c foo.c */
int get(void);
int use(int);
void foo(int bar)
{
int foobar;
if(!bar)
foobar = get
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC
--- Comment #3 from edwintorok at gmail dot com 2008-11-07 17:14 ---
(In reply to comment #2)
Subject: Re: New: 'warning: comparison between signed and
unsigned' shouldn't be given for equality comparisons
On Fri, 7 Nov 2008, edwintorok at gmail dot com wrote:
Consider
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http
--- Comment #1 from edwintorok at gmail dot com 2008-11-14 20:15 ---
Created an attachment (id=16677)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16677action=view)
original sourcecode
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
--- Comment #2 from edwintorok at gmail dot com 2008-11-14 20:18 ---
Created an attachment (id=16678)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16678action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
--- Comment #1 from edwintorok at gmail dot com 2008-11-15 13:56 ---
Created an attachment (id=16682)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16682action=view)
example to illustrate
compile with g++ -O3, I get:
real0m0.130s
user0m0.100s
sys 0m0.028s
compile
: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
--
edwintorok at gmail dot com changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
--- Comment #2 from edwintorok at gmail dot com 2008-11-15 21:59 ---
(In reply to comment #1)
Subject: Re: New: --enable-checking=all times out during bootstrap
Sent from my iPhone
On Nov 15, 2008, at 1:27 PM, edwintorok at gmail dot com
[EMAIL PROTECTED]
wrote:
I
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC
--- Comment #1 from edwintorok at gmail dot com 2008-11-22 08:21 ---
Testcase:
$ /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/
-B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -Wfatal-errors -c -O1
testcase-min.i
/* testcase */
typedef unsigned int UINT32
--- Comment #17 from edwintorok at gmail dot com 2008-11-24 18:33 ---
Created an attachment (id=16761)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16761action=view)
drivers/scsi/sd.c
Similar problem with drivers/scsi/sd.c
I can compile the attached preprocessed on x86_64 linux
of
__builtin_constant_p()
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org
--- Comment #3 from edwintorok at gmail dot com 2008-12-06 08:37 ---
This got fixed somewhere between r142405 and r142487, because
r142487 has bootstrapped successfully.
--
edwintorok at gmail dot com changed:
What|Removed |Added
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http
--- Comment #1 from edwintorok at gmail dot com 2008-03-19 18:54 ---
Created an attachment (id=15345)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15345action=view)
testcase
Some observations:
If you remove some dead code the optimization bug goes away:
Remove either
--- Comment #2 from edwintorok at gmail dot com 2008-03-19 19:35 ---
Created an attachment (id=15346)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15346action=view)
another reduced testcase
I reduced the testcase further using delta, however I had to be careful to
avoid deleting
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
--- Comment #1 from edwintorok at gmail dot com 2008-03-21 12:42 ---
Created an attachment (id=15353)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15353action=view)
reduced testcase
$ gcc-4.3 -O1 -g -ftree-vectorize test.i -o fails
$ gdb ./fails
GNU gdb 6.7.1-debian
Copyright (C
--- Comment #8 from edwintorok at gmail dot com 2008-03-23 16:59 ---
(In reply to comment #7)
Subject: Re: [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression:
incorrect code generation
This code violates c/c++ aliasing rules.
-Wstrict-aliasing doesn't give a warning
--- Comment #13 from edwintorok at gmail dot com 2008-03-24 17:00 ---
(In reply to comment #11)
I think the code is violating alignment requirements of the C/C++ standard.
First a real bug here is that -Wstrict-aliasing doesn't warn of this situation.
Do you agree?
Unaligned
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36524
--- Comment #2 from edwintorok at gmail dot com 2008-06-13 11:34 ---
(In reply to comment #1)
-fpch-preprocess is probably one of the keys?
Running cc1plus without -fpch-preprocess still leads to a crash.
[EMAIL PROTECTED]:~/llvm-svn/llvm/tools/clang/lib/Basic$
/usr/lib/gcc/x86_64
--- Comment #4 from edwintorok at gmail dot com 2008-06-13 12:01 ---
(In reply to comment #3)
Can you delete the preprocessed libstdc++ includes from /usr/lib?
Sure, I only had these:
$ find /usr/lib/ /usr/local/lib -name *.gch
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c
--- Comment #5 from edwintorok at gmail dot com 2008-06-13 13:37 ---
I have built with --enable-checking=yes (instead of all), because all was
taking too long.
It looks like a value of a pointer is invalid.
See the gdb session below.
What should I do next to help debug the problem
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37178
--- Comment #1 from edwintorok at gmail dot com 2008-08-20 17:52 ---
Created an attachment (id=16115)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16115action=view)
reduced testcase
the testcase is reduced from clamav's scanners.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8
13:17:41 UTC 2
GCC host
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC
--- Comment #1 from edwintorok at gmail dot com 2008-08-21 13:26 ---
Also -fdiagnostics-show-option doesn't show that the error is coming from
-pedantic:
$ gcc -Werror -pedantic x.c -c -fdiagnostics-show-option
cc1: warnings being treated as errors
x.c: In function foo:
x.c:10: error
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37190
--- Comment #3 from edwintorok at gmail dot com 2008-08-21 16:08 ---
(In reply to comment #2)
Thanks for the report anyway!
Ok, when is GCC 4.4 scheduled to be released?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37190
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host
--- Comment #1 from edwintorok at gmail dot com 2008-08-21 17:48 ---
Created an attachment (id=16122)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16122action=view)
preprocessed source
Generated with:
gcc --combine p1.c p2.c -c -save-temps
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from edwintorok at gmail dot com 2008-08-21 17:52 ---
(In reply to comment #2)
This sounds like a glibc bug really. glibc's headers has invalid C in it :).
why does --combine
Because GCC checks that the prototypes are compatible across translational
units
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64
--- Comment #1 from edwintorok at gmail dot com 2008-09-18 17:30 ---
Testcase:
extern int printf (__const char *__restrict __format, ...);
extern int strcmp (__const char *__s1, __const char *__s2);
extern int puts (__const char *__s);
typedef unsigned char uint8_t;
typedef unsigned int
--- Comment #2 from edwintorok at gmail dot com 2008-09-18 17:31 ---
Created an attachment (id=16357)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16357action=view)
config.log for gcc 4.4
Some more system info:
$ uname -a
Linux debian 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC
--- Comment #20 from edwintorok at gmail dot com 2010-01-27 12:35 ---
Thanks to Jakub for the hints.
This is not a bug in libstdc++/gcc:
the problem is that fork() is called when we already have threads (due to
openmp/libstdc++ parallel mode), and then you can call a limited number
: misoptimizes sha256!
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build
1 - 100 of 125 matches
Mail list logo
