https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
--- Comment #3 from thutt at vmware dot com ---
Thanks for the quick triage. If the optimizer is getting confused about
control / data flow, is it possible that it's making bad decisions for codegen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
--- Comment #1 from thutt at vmware dot com ---
Also using godbolt.org, this sample fails from 4.9.0 to trunk.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
Target Milestone: ---
/*
When compiled with the following options using the C compiler:
-Werror
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
Target Milestone: ---
#if 0
The program below, compiled with:
x86_64-vmk-linux-gnu-gcc (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
thutt at vmware dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
--- Comment #9 from thutt at vmware dot com ---
(In reply to Andrew Pinski from comment #8)
Since glibc controls the headers we (GCC) project cannot do anything.
???
From your standpoint of having cpp produce different output, I understand
your
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
--- Comment #5 from thutt at vmware dot com ---
(In reply to Andrew Pinski from comment #3)
(In reply to thutt from comment #2)
Can you please explain why it's invalid to return a double if SSE is
disabled?
SSE is an x86-specific hardware
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
The following example shows a defect in gcc 4.8 when using the
'-mno-sse2' command line option: SSE2 instructions are still
generated.
Compile with:
gcc-4.8 -m64 -O1 -mno-sse2 -c -o /tmp
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
The following example shows a defect in gcc 4.8 when using the
'-mno-sse' command line option: an error is reported when including
wchar.h.
Compile with:
gcc-4.8 -m64 -O1 -mno-sse -c -o /tmp/gungla.o /tmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
--- Comment #2 from thutt at vmware dot com ---
Can you please explain why it's invalid to return a double if SSE is disabled?
SSE is an x86-specific hardware implementation and has nothing to do with
language validity from my standpoint.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264
--- Comment #7 from thutt at vmware dot com ---
(In reply to Uroš Bizjak from comment #6)
(In reply to thutt from comment #5)
Does the same error exist in the 4.8 branch, or any other forward moving
branch?
No, 4.8 and newer branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264
--- Comment #9 from thutt at vmware dot com ---
(In reply to Uroš Bizjak from comment #8)
(In reply to thutt from comment #7)
(In reply to Uroš Bizjak from comment #6)
(In reply to thutt from comment #5)
Does the same error exist
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
A defect has been found in several versions of gcc with respect to the
'-mcld' option.
-mcld
This option instructs GCC to emit a cld instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57264
--- Comment #5 from thutt at vmware dot com ---
(In reply to Uros Bizjak from comment #3)
Author: uros
Date: Mon May 13 17:14:26 2013
New Revision: 198837
URL: http://gcc.gnu.org/viewcvs?rev=198837root=gccview=rev
Log:
PR target
--- Comment #21 from thutt at vmware dot com 2010-09-03 13:07 ---
(In reply to comment #8)
Is 'coverity' a compiler? I don't think so.
Coverity is not a tool that generates code, but it does perform
all the syntactic semantic analysis that a code-generating compiler
--- Comment #13 from thutt at vmware dot com 2009-02-10 14:34 ---
(In reply to comment #12)
(In reply to comment #11)
Uros, how hard to support this in x86 backend?
snip
OTOH, constraints should be used to support correct register
allocation for machine instructions
--- Comment #10 from thutt at vmware dot com 2009-01-22 13:59 ---
(In reply to comment #7)
The problem here is that you are using unitialized local register variables so
the register allocator does not know any better. Anyways it works correctly
on
the trunk and I don't have any
--- Comment #5 from thutt at vmware dot com 2009-01-21 13:06 ---
(In reply to comment #2)
I think this code is undefined as you are using uninitialized variables for
input of the inline-asm.
I disagree.
The registers are intended to have their *current*
values saved across
--- Comment #6 from thutt at vmware dot com 2009-01-21 13:08 ---
(In reply to comment #3)
Also I think the inline-asm could be improved so that the inline-asm just
marks
the registers that are clobbered instead of doing the mess you are doing.
Can you provide an example of how
assembly, generates bad code
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org
--- Comment #1 from thutt at vmware dot com 2009-01-20 21:27 ---
See bug 16331 too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
--- Comment #4 from thutt at vmware dot com 2008-12-23 15:40 ---
/*
I concur with Ulrich, but three years on, using gcc 4.1.2.
Although a parameter which is marked with the 'nonnull' attribute
is demonstrably nonnull, and although the compiler recognizes it is
specifically NULL
--- Comment #9 from thutt at vmware dot com 2008-12-23 15:44 ---
(In reply to comment #1)
The compiler may also choose to make optimizations based on
the knowledge that certain function arguments will not be null.
Witeness the last sentence.
If this is the case, then might
--- Comment #2 from thutt at vmware dot com 2008-12-16 14:03 ---
(In reply to comment #1)
The reason why they are saved is so that you can have a good way of debugging
noreturn functions.
Can you please elaborate? How is saving these registers, which will never be
restored, going
: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37148
--- Comment #18 from thutt at vmware dot com 2008-08-18 13:55 ---
This defect has been open nearly 4 years. Any hope of
actually getting a fix commited?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #17 from thutt at vmware dot com 2007-03-27 13:49 ---
In response to comment #16:
I wouldn't call an inliner which inlines functions specifically marked as do
not put this in '.text' as 'smart'. I'd use a more pejorative adjective, such
as 'broken' or 'dumb'.
--
http
--- Comment #19 from thutt at vmware dot com 2007-03-27 14:44 ---
I guess I need a bigger typeface because I don't see where it says
'(the out-of-line copy)'.
Or, perhaps, you've simply added that '(the out-of-line copy)'
annotation yourself because that's what the code currently does
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #1 from thutt at vmware dot com 2007-03-26 15:08 ---
Created an attachment (id=13288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13288action=view)
Simple Script which will build the original C source
Simple Script which will build the original C source
--
http
--- Comment #2 from thutt at vmware dot com 2007-03-26 15:09 ---
Created an attachment (id=13289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13289action=view)
original source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #3 from thutt at vmware dot com 2007-03-26 15:09 ---
Created an attachment (id=13290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13290action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #5 from thutt at vmware dot com 2007-03-26 15:40 ---
I'm going to argue that comment #4 is incorrect.
1. This new behavior is a regression from previous versions of gcc.
2. The 4.1.1 compiler gets it right at -O0 and -O3. Previous
versions of gcc which we've been
--- Comment #8 from thutt at vmware dot com 2007-03-26 15:57 ---
Furthermore,
4. By placing the code in a different section, I'm instructing the
the compiler to *not* put it in '.text'. By inlining it, it
places it in '.text' despite my instructions.
--
http
--- Comment #12 from thutt at vmware dot com 2007-03-26 17:46 ---
I respectfully submit that I think you guys are missing the point.
The problem isn't that the compiler is inlining functions which
are called once, the problem is that the compiler is inlining a
function
--- Comment #14 from thutt at vmware dot com 2007-03-26 18:54 ---
Why do you think sections are special?
GCC does not know if a section is special or not and it really should not
know.
I don't necessarily think that sections are 'special', but since gcc
has the capability to change
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
--- Comment #1 from thutt at vmware dot com 2007-03-23 15:02 ---
Created an attachment (id=13265)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13265action=view)
Simple script to build test program at all optimization levels
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
--- Comment #2 from thutt at vmware dot com 2007-03-23 15:03 ---
Created an attachment (id=13266)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13266action=view)
Simple source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
--- Comment #3 from thutt at vmware dot com 2007-03-23 15:03 ---
Created an attachment (id=13267)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13267action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
--- Comment #15 from thutt at vmware dot com 2007-03-23 15:51 ---
In regards to comment #13: In what tarball is this defect fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
42 matches
Mail list logo
