ssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- 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
--- 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
specifi
--- 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, t
f (_exp != _act) {
failure(_act, _exp);
}
}
return 0;
}
void
SetupVMCB(uint64 rip, unsigned cpl)
{
}
--
Summary: gcc ignores use of %rbp via 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/bugzilla/show_bug.cgi?id=38925
--- 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 #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 sav
--- 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 a
--- 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
at O1 and O2
Product: gcc
Version: 4.1.1
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=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=13265&action=view)
Simple script to build test program at all optimization levels
--
http://gcc.gnu.org/bugzilla/show_bug
--- 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=13266&action=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=13267&action=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
Product: gcc
Version: 4.1.1
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=13288&action=view)
Simple Script which will build the original C source
Simple Script which will build the original C
--- 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=13289&action=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=13290&action=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&#x
--- 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 i
--- 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
fun
--- 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 g
--- 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 pejorat
--- 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&
dBy: thutt 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 #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?
>
> OTOH, constraints should be used to support correct register
> allocation for machine in
--- Comment #15 from thutt at vmware dot com 2009-02-10 15:35 ---
(In reply to comment #14)
> > > OTOH, constraints should be used to support correct register
> > > allocation for machine instructions, not to emulate ABI in order to
> > > support calls
Severity: 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
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=198837&root=gcc&vie
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?
&
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)
> > &g
iority: P3
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
mponent: 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-sse' command line option: an error is reported when including
wchar.h.
Compile with:
gcc-4.8 -m64 -O1 -mno-sse -c -
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=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?
> &
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 unde
--- 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-gener
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.
This is
tatus: 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:
-W
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.
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?
43 matches
Mail list logo
