https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527
Linus Torvalds changed:
What|Removed |Added
CC||torvalds@linux-foundation.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527
--- Comment #4 from Linus Torvalds ---
(In reply to Jeffrey A. Law from comment #3)
> GCC already knows that free() "kills" the pointed-to memory and should be
> doing DSE with that in mind. It doesn't however know that other functions
> have fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527
--- Comment #8 from Linus Torvalds ---
(In reply to Jonathan Wakely from comment #6)
> I can see uses that aren't just "frees the memory", e.g. after fclose and
> close any further uses of their argument are probably errors. The close case
> is i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94522
Linus Torvalds changed:
What|Removed |Added
CC||torvalds@linux-foundation.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94522
--- Comment #5 from Linus Torvalds ---
Btw, Nick (who is doing this on the clang side, tells me that the tcmalloc
people are looking at using the asm goto with outputs too, so it's not just the
kernel.
If somebody wants to play with it, I do hav
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: torva...@linux-foundation.org
Target Milestone: ---
Created attachment 45820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45820&action=edit
You can compile this to see a lack of warning.
We had a simple kerne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #2 from Linus Torvalds ---
(In reply to Andrew Pinski from comment #1)
> I think it comes down to the same issue as PR 18501.
Very possibly the same issue in just a different guise.
NOTE! I have in the meantime verified that yes, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #6 from Linus Torvalds ---
(In reply to Richard Biener from comment #5)
>
> And this meeting helps us avoid bogus warnings for cases where GCC has
> difficulties proving dead code paths are actually dead ...
Ack. I do see the diffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #8 from Linus Torvalds ---
(In reply to Jeffrey A. Law from comment #7)
> It's reliably the case that a false positive uninit warning also represents
> a failure to optimize something. So we've got significant incentives to
> deeply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #10 from Linus Torvalds ---
(In reply to ncm from comment #9)
> What I don't understand is why it doesn't optimize away the check on
> (somecondition), since it is assuming the code in the dependent block always
> runs.
No, it very m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #12 from Linus Torvalds ---
(In reply to Jeffrey A. Law from comment #11)
>
> More generally we have considered whether or not we could eliminate the
> control dependent path which leads to undefined behavior. But you have to
> be
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: torva...@linux-foundation.org
gcc-4.9.0 in Debian seems to miscompile the linux kernel for x86-64 in certain
configurations, creating accesses to below the stack pointer even though the
kernel uses -mno-red-zone.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
--- Comment #1 from Linus Torvalds ---
Created attachment 33183
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33183&action=edit
Buggy result of compilation
This was sent by the reporter of the kernel problem, Michel Dänzer
, at my request
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
--- Comment #3 from Linus Torvalds ---
Created attachment 33184
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33184&action=edit
gzipped pre-processed fair.i file
Apparently attaching a file during the initial bug entry creation failed,
pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
--- Comment #4 from Linus Torvalds ---
As I already mentioned to Jakub Jelinek separately in the original email thread
about the kernel problem:
"Note that I don't personally have a reproducer (my machine has
gcc-4.8.3, and I don't see the sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
--- Comment #7 from Linus Torvalds ---
Just for completeness for the original bug report, here's the actual compiler
command line that the kernel uses to generate the *.s file.
gcc -Wp,-MD,kernel/sched/.fair.s.d -nostdinc -isystem
/usr/lib/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
--- Comment #8 from Linus Torvalds ---
Oh, and this is marked as a duplicate of 61801, but that one is marked to be in
gcc-4.8.3
The particular problem we see in kernel code generation seems to *not* happen
in 4.8.3 (current fedora 20), and happ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
--- Comment #10 from Linus Torvalds ---
(In reply to Andrew Pinski from comment #9)
>
> The bad compiler versions are 4.5.0 (when debug_insn came in) to 4.8.3 and
> 4.9.0 and 4.9.1.
Ok, so we have no reasonable way of avoiding the problem compi
: unassig...@gcc.gnu.org
ReportedBy: torva...@linux-foundation.org
gcc (tried 4.5.1 and 4.6.0) generates absolutely horrid code for some common
bitfield accesses due to minimizing the access size.
Trivial test case:
struct bad_gcc_code_generation {
unsigned type:6,
pos:16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #1 from Linus Torvalds 2011-04-20
04:28:18 UTC ---
Side note, this is talked about in the Intel optimization manual
3.6.4 Store Forwarding
Under "General Optimization Guidelines" -> "Optimizing Memory Accesses" ->
"Store Forwardin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #7 from Linus Torvalds 2011-04-20
15:30:17 UTC ---
(In reply to comment #2)
>
> I'm not sure where to best address this, rather than throwing in again
> the idea of lowering bitfield accesses early on trees.
So my gut feel is that g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #11 from Linus Torvalds 2011-04-20
16:16:52 UTC ---
(In reply to comment #8)
>
> Unfortunately the underlying type isn't easily available (at least I didn't
> yet find it ...). But I suppose we have to guess anyway considering
> tar
: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: torva...@linux-foundation.org
This trivial code:
extern void fncall(void *);
int main(int argc, char **argv)
{
if (!--*argv)
fncall(argv);
return 0;
}
compiles into this ridiculous x86-64 assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095
--- Comment #2 from Linus Torvalds 2011-05-21
18:41:15 UTC ---
(In reply to comment #1)
>
> On the RTL side combine tries to do
>
> Trying 7, 8 -> 9:
> Failed to match this instruction:
> (parallel [
> (set (mem/f:DI (reg/v/f:DI 63 [ arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095
--- Comment #3 from Linus Torvalds 2011-05-21
20:42:26 UTC ---
Hmm. Looking at that code generation, it strikes me that even with the odd load
store situation, why do we have that "test" instruction?
c:8b 10mov(%ea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095
--- Comment #6 from Linus Torvalds 2011-05-27
14:15:25 UTC ---
Jakub - the patch looks sane, although I don't currently have a gcc build
environment to actually test it with, and there is no way I'm going to claim
that I follow all the matches an
...@gcc.gnu.org
ReportedBy: torva...@linux-foundation.org
So gcc inlining heuristics seem to include the rule that if it's called from a
single call-site, and is static, then it should be inlined.
That is actually really horrible for some cases.
In particular, if you have a small fun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095
--- Comment #8 from Linus Torvalds 2011-05-27
15:32:21 UTC ---
(In reply to comment #7)
>
> BTW, the patch bootstrapped/regtested on both x86_64-linux and i686-linux, I'm
> just running second set of bootstrap without the patch to be able to comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194
--- Comment #6 from Linus Torvalds 2011-05-27
16:38:22 UTC ---
(In reply to comment #3)
>
> -finline-functions-called-once is trottled down by the large-function-growth
> and large-stack-frame-growth limits. The Kernel case coupld proably be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095
--- Comment #10 from Linus Torvalds 2011-05-27
16:48:52 UTC ---
(In reply to comment #9)
>
> 32-bit before32-bit after64-bit before64-bit after
> libstdc++.so.60x717080x716e80x67ee60x67ec6
> libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095
--- Comment #13 from Linus Torvalds 2011-05-29
18:56:44 UTC ---
Thanks guys.
31 matches
Mail list logo
