--- Comment #26 from pinskia at gcc dot gnu dot org 2007-06-30 00:30
---
As mentioned many times, libgcc is correct and the issue with the libgcc is a
kernel issue. Yes GCC should not be emitting udivid3 in the case of the loop
but that is a different bug which is still open.
--
pi
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-06-30 00:29
---
Hello anyone in here? I guess you did not see my comment about the code gen
issue is going to be fixed. The issue with the library is a different problem
and not really an GCC issue and that if the programer uses
--- Comment #24 from malitzke at metronets dot com 2007-06-30 00:22 ---
Mr. Torvalds has already answered in comment 1
--
malitzke at metronets dot com changed:
What|Removed |Added
---
--- Comment #23 from malitzke at metronets dot com 2007-06-30 00:18 ---
Segher was mentioned twice. First, according to my research he is not a kernel
maintainer as implied in comments 4 and 9. He is actuallu Segher Boessenkool, a
GCC maintainer, inactive since 2005-02-01, his latest em
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-06-29 23:57
---
When I am saying GCC is doing the correct thing, I am talking about the library
issue and not about the code gen issue (the code gen issue is filed in a
different bug and will be fixed, it just takes time though yo
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-06-29 23:55
---
How many times do I and others, GCC is doing the correct thing?
If you want to ping someone, go talk to Linus.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from malitzke at metronets dot com 2007-06-29 23:53 ---
Ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #19 from schwab at suse dot de 2007-06-29 22:34 ---
There is no violation of any C standard.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #18 from malitzke at metronets dot com 2007-06-29 22:19 ---
As I am clearly rejected by the GCC insiders in my attempts to help make the C
compiler more attuned to the spirit of the C99 committee; I am now forced to
alert the user community of what is happening with a near
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-06-29 21:45
---
1) The compiler needs a support library to implement all required features in
the standard.
2) That library is libgcc.
3) Linux kernel has its own support library for these functions
4) The linux kernel support lib
--- Comment #16 from malitzke at metronets dot com 2007-06-29 21:42 ---
A treaty is a bilateral agreement. No something shoved down one Side throat.
The worse I look the more I accomplish for others than GCC fanatics
--
malitzke at metronets dot com changed:
What|Rem
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-29 21:20
---
> A standard is a __treaty__ (contract) between implementor and programmer.
And in our implementation, there is a library for support functions. If you
don't see that, then please stop your rants. Your rants act
--- Comment #14 from malitzke at metronets dot com 2007-06-29 21:14 ---
The first two sentences of your comment was never disputed by either myself nor
from how I read Mr Torvald's comment.
The only thing under dispute is the completely unwarrented trnasformation of a
subtraction into
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-28 19:06
---
Again please read What I wrote about what the C99 standard requires. It
requires long long support for a freestanding compiler. So that is provided
with libgcc. If the Linux kernel team decides that they don't w
--- Comment #12 from malitzke at metronets dot com 2007-06-28 03:53 ---
Mr Pinski! Thanks for again doing the work for me.
I just had to take some time out for my annual checkup and to rebuild my big
machine's software after Gentoo on shutdown -h now deleted my /bin, /etc, and
/sbin dir
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-25 17:12
---
The standard is clear that long long is fully supported by freestanding
programs which means that the implementation needs to support it. GCC supports
it by providing libgcc.a support library.
4/6:
The two forms o
--- Comment #10 from malitzke at metronets dot com 2007-06-25 17:01 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
CC|rguenth at g
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-25 13:06 ---
Now you are getting annoying. Richard closed the bug already too. Please read
my whole comments and Segher's. Nobody has really looked into the code
produced except for the fact GCC is emitting a call to divdi3 wh
--- Comment #8 from malitzke at metronets dot com 2007-06-25 13:03 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-25 12:53 ---
What is there to ping?
The problem again is in the Linux kernel.
Please read http://lkml.org/lkml/2007/5/18/371 as I mentioned before.
Linus is incorrect. GCC is not ignoring unlikely as the divide is only
reac
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-25 12:53 ---
Pong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRME
--- Comment #5 from malitzke at metronets dot com 2007-06-25 12:50 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-25 12:37 ---
Huh? This bug is invalid. Linus is incorrect. Please read all the emails
including Segher's. Note GCC is not ignorining unlikely at all (except maybe
for a code size issue).
--
pinskia at gcc dot gnu dot org
--- Comment #3 from malitzke at metronets dot com 2007-06-25 12:35 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-25 12:33 ---
Also by the way the divide is only inside the unlikely part of the code so it
will not slow down the common code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 12:16 ---
You need to learn this is not a bug.
if you do:
long long f(long long a, long long b)
{
return a/b;
}
You will get a reference to divdi3. There is no bug here except inside the
lInux kernel.
Linus is wrong in s
26 matches
Mail list logo
