AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davmac at davmac dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
--- Comment #1 from davmac at davmac dot org 2007-01-21 14:15 ---
I should add that I'm prepared to send a patch for the documentation if someone
will tell me what the operands are and what they do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
--- Comment #3 from davmac at davmac dot org 2007-01-22 04:17 ---
You've got to be kidding - these things are genuinely useful. What sort of
abuse are you worried about?
In any case, I'd like to know if that is the general consensus among
maintainers. I'm not going to write
--- Comment #1 from davmac at davmac dot org 2009-10-28 10:41 ---
Urgh. By paragraph above I am of course referring to the same paragraph.
However, the basic point - that enabled seems to be used with two different
meanings - stands.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davmac at davmac dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
--- Comment #4 from Davin McCall davmac at davmac dot org ---
I recently stumbled across section 6.43.2.7 of the manual, which does in fact
document the operand modifiers for (and only for) x86. Modifiers for other
architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81516
--- Comment #4 from Davin McCall ---
(In reply to Andrew Pinski from comment #3)
> Most likely a dup of bug 323.
I don't think so, unless I'm misunderstanding something. There's no rounding in
the test case, just a store of an int value to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81516
--- Comment #7 from Davin McCall ---
(In reply to Uroš Bizjak from comment #6)
>
> Works OK for me with:
>
> .ident "GCC: (GNU) 7.1.1 20170718 [gcc-7-branch revision 250314]"
Reported against 7.1.0. It may well be fixed already on
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: davmac at davmac dot org
Target Milestone: ---
Created attachment 41809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41809=edit
reduced test case
Attached file (reduced test case from string-to-double convers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81516
--- Comment #1 from Davin McCall ---
(triggers with -march=prescott|haswell, not with -march=i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569
--- Comment #2 from Davin McCall ---
Still happening in 7.1.
-march=core2 suppresses, generation of the problematic instruction happens with
-march=haswell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569
--- Comment #4 from Davin McCall ---
(In reply to Uroš Bizjak from comment #3)
> Can you please test attached patch?
That seems to fix the problem, yes. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81516
--- Comment #8 from Davin McCall ---
This problem disappears when I apply the fix for #80706 (as applied to GCC 7
branch). Possibly this is a duplicate of that issue.
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davmac at davmac dot org
Target Milestone: ---
The following code (reduced via creduce) gives a warning, when compiled with:
g++ -std=c++11 -Os -Wall -Wno-invalid-offsetof -c dinit-warn.cc
dinit-war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
--- Comment #1 from Davin McCall ---
(Does not actually require -Wno-invalid-offsetof to reproduce; that was just me
copying my command line literally. Problem first appears in GCC 6.1, not in
5.x, still present in 7.1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569
--- Comment #1 from Davin McCall ---
(Prevents building Qemu).
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: davmac at davmac dot org
Target Milestone: ---
The following code, compiled with -m16 -O2 -c, fails at assembly:
--- begin ---
void load_kernel(void *setup_addr)
{
unsigned int seg = (unsigned int)setup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #61 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #59)
> (In reply to Davin McCall from comment #56)
> > (In reply to James Kuyper Jr. from comment #55)
> > > The problem is, you're using a statement that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #54 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #53)
> [...] However, because those
> pointers are passed to f(), which does dereference them, f() does accesses
> those members, and it does so via the use of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #56 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #55)
> The problem is, you're using a statement that the access must occur via a
> union, with the implication that the code in question does not access the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #58 from Davin McCall ---
(In reply to Andrew Haley from comment #57)
> (In reply to Davin McCall from comment #52)
> > (In reply to Andrew Haley from comment #45)
> > > (In reply to Davin McCall from comment #44)
> > > > The "one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #52 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #48)
> > The "one special guarantee" clause appears in the section describing union
> > member access via the "." or "->" operators, implying that it only applies
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #44 from Davin McCall ---
> Well, perhaps not, but this is the language specification.
The "one special guarantee" clause appears in the section describing union
member access via the "." or "->" operators, implying that it only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #27 from Davin McCall ---
(In reply to Martin Sebor from comment #24)
> The code in example #21 has the same bug:
> [...]
... due to provenance, you are claiming, if I understand correctly. But I don't
see anything in the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #20 from Davin McCall ---
(In reply to Davin McCall from comment #19)
> [...] If the result of offsetof has no provenance even the long form won't
> work.
"no provenance" meaning "empty provenance", and of course this is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #21 from Davin McCall ---
Looking at this further, the proposal actually states, for the address-of
operator:
> When the operand designates an object, the result has the single provenance
> of the outermost object containing that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #23 from Davin McCall ---
(In reply to Martin Sebor from comment #22)
> The test cases in this report are variations on this theme. [...]
Ok, except that the one I posted in comment #21 specifically copies the string
into a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
--- Comment #8 from Davin McCall ---
(In reply to ensadc from comment #7)
> Note that the "never defined" part is also misleading: the warning persists
> when `i::dispatch` does have a definition
Yes; and actually, I note that in the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
--- Comment #6 from Davin McCall ---
> The wording could be improved, but why do you think the warning is spurious?
I guess I think that the warning is spurious given the current wording? It may
well be legitimate to warn that there is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268
--- Comment #5 from Davin McCall ---
Hi Richard,
I think you marked as a duplicate of the wrong bug. It is indeed a duplicate of
82224 - sorry, I didn't realise that there was already a bug filed, also this
test case is "fixed" by version 8.1
Assignee: unassigned at gcc dot gnu.org
Reporter: davmac at davmac dot org
Target Milestone: ---
The following code is adapted from an LLVM PR:
https://bugs.llvm.org/show_bug.cgi?id=34632
The "test" function is called with all three pointers pointing to the same
un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268
--- Comment #1 from Davin McCall ---
(fails with -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #3
38 matches
Mail list logo
