http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
Bug #: 56715
Summary: Explicit Reg Vars are being ignored for consts when
using g++
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
--- Comment #2 from Goswin von Brederlow goswin-v-b at web dot de 2013-03-25
00:07:19 UTC ---
(In reply to comment #1)
const is a bit special in C++, it can be used as part of a const integer
expression which is what is happening here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
Goswin von Brederlow goswin-v-b at web dot de changed:
What|Removed |Added
Status|RESOLVED
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: arm-none-eabi
I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65262
--- Comment #2 from Goswin von Brederlow goswin-v-b at web dot de ---
The linker script is only there because the default script combines all .text.*
into one hiding the effect. One could use different section names that the
default script does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65252
--- Comment #2 from Goswin von Brederlow goswin-v-b at web dot de ---
As long as it's only one C/C++ file that works. But if one has multiple files
then -fno-lto would optimize less. I was thinking of a more general case than
mine.
: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
Created attachment 34911
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34911action=edit
Simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65199
--- Comment #2 from Goswin von Brederlow goswin-v-b at web dot de ---
That fixes it. Isn't it a gcc bug though not to detect that itself?
: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: arm-none-eabi
I'm building a bare-metal kernel for a Raspberry Pi 2 (armv7) in c++. At some
point this failed with undefined
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Build: arm-none-eabi
I have a uint64_t free running counter with a frequenzy of 1Mhz and I want to
print
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699
--- Comment #4 from Goswin von Brederlow goswin-v-b at web dot de ---
Yes, a simple statement like that was exactly what I had in mind.
Severity: enhancement
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
The online docs do not mention what version of the compiler they document. When
something
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
https://gcc.gnu.org/onlinedocs/gccint/Collect2.html says when collect2 is used
it generates a temporary file listing the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #15 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #14)
> (In reply to Goswin von Brederlow from comment #13)
> > > > Secondly why pass error_code as argument if is already on the stack and
> > > > could be accessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #17 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #16)
> (In reply to Goswin von Brederlow from comment #15)
>
> > > No. We only do it for data pushed onto stack by CPU.
> >
> > I was thinking of something like:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
Goswin von Brederlow changed:
What|Removed |Added
CC||goswin-v-b at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #13 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #12)
> (In reply to Goswin von Brederlow from comment #11)
> > I think the design is fundamentally lacking in the following points:
> >
> > 1. interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #20 from Goswin von Brederlow ---
So it's been a year since my last comment. Is this dead or is someone still
working on it? It would be a nice addition to gcc.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
Trying to access a pointer cast from an integer literal gives a out of bounds
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #29 from Goswin von Brederlow ---
(In reply to Jakub Jelinek from comment #26)
> That is nonsense. The amount of code in the wild that relies on (type
> *)CONSTANT
> working is insane, you can't annotate it all. And it has worked
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
In the embedded and micro controller world memory mapped registers are very
common. They can be declared as external object and fudged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #38 from Goswin von Brederlow ---
(In reply to Jonathan Wakely from comment #34)
> (In reply to Goswin von Brederlow from comment #29)
> > There is no garantee in the C standard that '(type *)CONSTANT' will actually
> > point to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
--- Comment #3 from Goswin von Brederlow ---
Created attachment 53082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53082=edit
Working patch for detecting UB
This will abort if the arguments are too large instead of static_assert, best
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
Running "gcc-12.1 -std=c++20 -O2 -W -Wall" on
#include
constinit int t = std::lcm(50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
Goswin von Brederlow changed:
What|Removed |Added
CC||goswin-v-b at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
--- Comment #2 from Goswin von Brederlow ---
I know the patch doesn't work yet, the static_asserts aren't constexpr. But
hopefully it gives someone enough of an idea to fix it.
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
I'm trying to compute (a*a)%n for uint64_t types on x86_64 using "gcc -O2 -W
-Wall" like this:
#include
#include
uint64_t sqrmod(uint64_t a, uint64_t n) {
as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521
--- Comment #3 from Goswin von Brederlow ---
(In reply to Andrew Pinski from comment #1)
> This requires having a, 64bit/32bit (and 128bit/64bit) pattern really. So
> this is both a middle-end issue and a target issue.
>
> Note there might be
28 matches
Mail list logo
