https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #3
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 an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268
--- Comment #1 from Davin McCall ---
(fails with -O2)
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=95189
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #28
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 te
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 declara
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 lan
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 mem
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 ob
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 actually
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=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 access
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 spe
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
> member
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 #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 appl
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=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.
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 #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 the
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 dou
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=81516
--- Comment #1 from Davin McCall ---
(triggers with -march=prescott|haswell, not with -march=i686)
: 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&action=edit
reduced test case
Attached file (reduced test case from string-to
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).
Priority: 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
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=65892
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #25
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=30527
--- Comment #4 from Davin McCall ---
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 are not documented.
--- 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/b
(and wrong)
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: 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
--- 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
--- 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
rity: normal
Priority: P3
Component: c
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
38 matches
Mail list logo
