https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #26 from Thorsten Kurth ---
Hello Jakub,
thanks for the clarification. So a team maps to a CTA which is somewhat
equivalent to a block in CUDA language, correct? And it is good to have some
categorical equivalency between GPU and CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81182
Marcin Grzebieluch changed:
What|Removed |Added
CC||grzebieluch at me dot com
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbza at bluematt dot me
Target Milestone: ---
I'm not sure whether the standard has any thread-safety requirements for
std::local::classic() (I cant seem to find any?), but it seems needlessly
race-y:
classic() constru
++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at ryanlewis dot net
Target Milestone: ---
Created attachment 40218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40218&action=edit
example of failing code (which isn't failing)
I am working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78636
--- Comment #1 from rhl ---
Created attachment 40219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40219&action=edit
this is the valgrind output when the segfault occurs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78636
--- Comment #2 from rhl ---
Created attachment 40220
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40220&action=edit
and the output of valgrind after remove offending Output function in favor out
std::cout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78636
--- Comment #4 from rhl ---
Created attachment 40238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40238&action=edit
this is the output of make when -v -save-temps=obj was added
I tried to attach the preprocessed sources but there is far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78636
--- Comment #5 from rhl ---
Also, some system information for reference:
[fedora@puiterwijk---rhl-ppc ~]$ cat /proc/cpuinfo
processor : 0
cpu : POWER8E (raw), altivec supported
clock : 3425.00MHz
revision
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhouyan at me dot com
Target Milestone: ---
Here is a minimal example,
#include
#ifdef major
#error
#endif
The example check if there's a macro named "major" defined. I observed this
recently when
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at haldean dot org
Target Milestone: ---
Created attachment 40729
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40729&action=edit
C++ source that exercises the poor dia
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: me at manueljacob dot de
CC: amker at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
Created attachment 40787
--> ht
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: me at manueljacob dot de
CC: jakub at gcc dot gnu.org, rguenther at suse dot de
Target Milestone: ---
Created attachment 40814
--> https://gcc.gnu.org/bugzi
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: me at manueljacob dot de
CC: amker at gcc dot gnu.org, jakub at redhat dot com,
rguenth at gcc dot gnu.org
Target Milestone: ---
This happens at least on x86-64 with -ftree-slp-vectorize
Assignee: unassigned at gcc dot gnu.org
Reporter: me at manueljacob dot de
CC: jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
void fill(unsigned char __seg_gs *arr, unsigned char c, long n) {
for (long i = 0; i < n;
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: damien at iwi dot me
Target Milestone: ---
Hi,
It seems that `diagnostic ignored -Wcomment` has no effect.
Since nothing states that it does not work, I would expect no warning here.
Thanks :)
``
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79701
--- Comment #1 from Damien GERARD ---
behavior observed:
- debian 9 with gcc 6.3 & 5.4
gcc (Debian 6.3.0-7) 6.3.0 20170218
gcc-5 (Debian 5.4.1-5) 5.4.1 20170205
- CentOS 7.2 gcc 6.2 (rhel-devtoolset)
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: me at manueljacob dot de
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
void memset_pattern_seg_gs(unsigned char * __seg_gs *s, long n) {
for (long i = 0; i < n; ++i)
s[i] = 0;
}
On
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dmarion at me dot com
Target Milestone: ---
$ gcc -march=nehalem -O3 -o a.o a.c -c -g2 -Wall -Wextra
a.c: In function ‘foo_avx2’:
a.c:15:38: internal compiler error: in
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at hussam dot eu.org
Target Milestone: ---
6.3 20160309 snapshot works fine but latest git from gcc-6 branch results in an
internal compiler error:
/usr/bin/g++ -std=gnu++11 -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80091
--- Comment #3 from Hussam Al-Tayeb ---
Thank you. I was rushing home to retry.
6.3 20160309 snapshot works for sure. So it regressed sometime in the last few
days.
: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at pkh dot me
Target Milestone: ---
Using DJGPP, requested alignment is not clamped anymore:
[/tmp]☭ echo 'int __attribute__ ((aligned (16))) x;' > a.c &&
i686-pc-msdosdjgpp-cc -c
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: damien at iwi dot me
Target Milestone: ---
>From g++ 6.2 to g++ 7, defining several times the same constexpr variable makes
gcc crash:
constexpr char text1[] = "hello world&quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80289
Damien GERARD changed:
What|Removed |Added
Attachment #41104|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80289
--- Comment #2 from Damien GERARD ---
Seems to be a regression :)
$ /usr/bin/g++ --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80289
--- Comment #3 from Damien GERARD ---
Oh m(In reply to Damien GERARD from comment #0)
> From g++ 6.2 to g++ 7, defining several times the same constexpr variable
> makes gcc crash:
My mistake, it seems to be fixed in g++ 6.3 and works as expecte
++
Assignee: unassigned at gcc dot gnu.org
Reporter: thorstenkurth at me dot com
Target Milestone: ---
Dear Sir/Madam,
I run into linking issues with gcc (GCC) 7.1.1 20170718 and OpenMP 4.5 target
offloading. I am compiling a mixed fortran/C++ code where target regions can be
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81896
--- Comment #1 from Thorsten Kurth ---
Hello,
is this report actually being worked on? It is in unconfirmed state for quite a
while now.
Best Regards
Thorsten Kurth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #28 from Thorsten Kurth ---
Hello,
can someone please give me an update on this bug?
Best Regards
Thorsten Kurth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81896
--- Comment #2 from Thorsten Kurth ---
Hello,
another data point:
when I create a dummy variable, it works: for example alias data to tmp and
then use tmp. I think this is not working for the same reason one cannot
arbitrarily put class member v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82629
--- Comment #2 from Thorsten Kurth ---
Created attachment 42420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42420&action=edit
This is the test case demonstrating the problem.
Linking this code will produce:
-bash-4.2$ make main.x
g++ -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82629
--- Comment #3 from Thorsten Kurth ---
One more thing,
In the test case I send, please change the $(XPPFLAGS) in the main.x target
compilation to $(CXXFLAGS), so that -fopenmp is used at link time also.
However, that does not solve the problem b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82629
--- Comment #4 from Thorsten Kurth ---
Hello Richard,
Was the test case received?
Best Regards
Thorsten Kurth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82134
Arne Vogel changed:
What|Removed |Added
CC||arvo at me dot com
--- Comment #4 from
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bradfier at fstab dot me
Target Milestone: ---
Follow up from ML post here: [1]
I tried compiling the following simple function with different -march flags in
-m32 mode:
> uint64_t sum(uint64_t a, uint64_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83068
--- Comment #1 from Richard Bradfield ---
And as usual I forget to mention these things:
I am compiling everything using gcc trunk, at commit r254929 from Sun Nov 19
This behaviour is not present in GCC 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83068
--- Comment #3 from Richard Bradfield ---
I bisected forward from a few months ago.
The proximate cause is commit r253934, specifically the reduction in cost of
the SSE Load & Store ops, and the costs of moving SSE to and from integer regs.
The
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.rigby at me dot com
Target Milestone: ---
Created attachment 39582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39582&action=edit
deque_alloc_test.cc
I'm observing a performance issue under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77524
--- Comment #2 from Dave Rigby ---
Hi Jonathan,
Thanks for the context - useful to know why the current behaviour is the case
(even if not ideal).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77524
--- Comment #3 from Dave Rigby ---
As an aside, std::queue<> (defaulting to using std::deque as the underlying
Container) suffers from a similar issue - I see 4 allocations for an empty
std::queue. Is this the same underlying issue, or should I r
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.rigby at me dot com
Target Milestone: ---
Spun out from bug 77524 - std::queue (defaulting to using std::deque as the
underlying Container) performs 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77524
--- Comment #5 from Dave Rigby ---
(In reply to Jonathan Wakely from comment #4)
> Please create a new bug for those container adaptors, as that can and should
> be fixed for the default configuration. We'll keep this bug for the
> non-backwards-
: unassigned at gcc dot gnu.org
Reporter: ab at fmap dot me
Target Milestone: ---
Created attachment 39758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39758&action=edit
test.cpp
This piece of code (minimized as far as I tried) causes a segfault on GCCs
6.2.0 and 6.2.1
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kergonath at me dot com
In the following program:
program stringtest
character(:), dimension(:), allocatable :: s
allocate(character(1) :: s(10))
write(*,*) size(s)
write(*,*) len(s)
end program
the elements of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795
--- Comment #4 from Kergonath ---
The slightly modified version:
module m
contains
subroutine allocate_array(s_array)
character(:), dimension(:), allocatable, intent(out) :: s_array
allocate(character(2) :: s_array(10))
NCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arvo at me dot com
Simplified source (compile with -std=c++11):
namespace not_here
{
template
struct Buzz;
} // namespace not_here
namespace here
{
templ
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arvo at me dot com
Created attachment 35160
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35160&action=edit
Preprocessed source
System report:
OS: GN
; so, please submit your trunk patch to gcc-patc...@gcc.gnu.org for review. If
> not, ask on the g...@gcc.gnu.org list for the paperwork to be sent to you.
Sorry, it took me a while to obtain the paperwork, and even longer to get
around to submitting it.
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01377.html
_as_macro() anyway.
> Simplify here also.
I don't see anything in version_as_legacy_macro() that specifically deals with
major <= 9. Could you point me to the offending code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #25 from Lawrence Velázquez ---
(In reply to m...@gcc.gnu.org from comment #22)
> Though I approved it on list, you should feel free to update with the review
> points others have and post that version if you wish.
Re-roll posted:
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
Lawrence Velázquez changed:
What|Removed |Added
Attachment #34010|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
Lawrence Velázquez changed:
What|Removed |Added
Attachment #34011|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
Lawrence Velázquez changed:
What|Removed |Added
Attachment #34012|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #31 from Lawrence Velázquez ---
(In reply to m...@gcc.gnu.org from comment #27)
> Fixed in 6.0. Backports pre approved after bake time and testing that
> includes older darwins and ppc.
Thanks! I've attached updated patches against 4
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thorstenkurth at me dot com
Created attachment 32071
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32071&action=edit
Archive which includes test ca
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kergonath at me dot com
Target Milestone: ---
When compiled with -fcheck=all, the included code crashes with the following
error message:
At line 16 of file foo.f90
Fortran runtime error: Recursive call to nonrecursive
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arvo at me dot com
Target Milestone: ---
Created attachment 36334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36334&action=edit
Minimal test program (no headers/mac
y: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arvo at me dot com
Target Milestone: ---
Created attachment 36367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36367&action=edit
Minimal test program (no h
: unassigned at gcc dot gnu.org
Reporter: quentin at pradet dot me
gcc.gnu.org doesn't have a 404 page, and the default Apache 404 page is a bit
terse. See https://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html.
(This bug was originally reported to the www.gnu.org webmasters. Feel free to
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adrien at guinet dot me
I think there is an issue with the way gcc uses the __attribute__ information
when generating SIMD load instructions d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64655
--- Comment #1 from Adrien Guinet ---
Created attachment 34476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34476&action=edit
test case reproducing the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64655
--- Comment #3 from Adrien Guinet ---
I don't think this is a user error. Some attributes might be declared aligned
inside a structure, without any specifications that every instanced objects
must be themselves aligned on a specific boundary. Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64655
Adrien Guinet changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64655
--- Comment #5 from Adrien Guinet ---
Moreover, the test case runs fine without any automatic vectorisation and
crashes when it is applied, so from my point of view there is something wrong
with this optimisation!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64655
Adrien Guinet changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64655
--- Comment #10 from Adrien Guinet ---
Well, okay, that implication didn't look that obvious. Sorry for the constant
bug reopening, it was not my intent. And thanks for the clarifications!
s: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: adrien at guinet dot me
Created attachment 34553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34553&action=edit
test case
The code
nt: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: simendsjo at simendsjo dot me
The following short example is a (somewhat reduced) example from
Bjarne Stroustroups book Programming Principles and Practice using
C++ 2nd edition first print, section 8.5.9 on page 290.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64842
--- Comment #2 from simendsjo at simendsjo dot me ---
(In reply to Ville Voutilainen from comment #1)
> The constructors for Point are constexpr, but since p2 is not, passing
> it as an argument for scale() means that the invocation of
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: me at williamgrant dot id.au
The aarch64 target, from 4.8.0 to today's master (tested up to 4b686186), drops
an "and x0, x0, #0x7" in some integer-only code when built with
-mgeneral-regs-only. Ig
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhouyan at me dot com
Below is a minimum example,
#include
int main ()
{
std::mt19937 eng;
std::normal_distribution<> rnorm;
_Cilk_for (int i = 0; i != 1; ++ i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64318
--- Comment #1 from zhouyan at me dot com ---
I forgot to mention that, the system is CentOS 7 (with all updates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64318
--- Comment #3 from zhouyan at me dot com ---
Here is version that shall be thread-safe, that produce the same problem,
#include
int main ()
{
_Cilk_for (int i = 0; i != 1; ++i) {
std::mt19937 eng(i);
std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64318
--- Comment #4 from zhouyan at me dot com ---
The new example can be unsafe, if the constructor of the two classes are
unsafe. However, I went through the source of before (during 4.8, 4.9
release), unless something changed, it's not the case.
Assignee: unassigned at gcc dot gnu.org
Reporter: danlnagle at me dot com
Target Milestone: ---
Created attachment 36094
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36094&action=edit
source causing ICE
This was discovered when testing leading-edge features from coarrays.
Pro
ty: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arvo at me dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target
el: posix
gcc version 4.6.0 20110129 (experimental) (GCC)
The operating system is Mac OS X 10.6.6, gcc is installed from Mac Ports 1.9.2.
The code itself is not legitimate, but compiler should not crash. So priority
is minor.
Please let me know if you need more details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48923
Summary: Type with Allocatable Length Character Component
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49076
--- Comment #2 from Andrew Baldwin 2011-05-21
03:16:20 UTC ---
I'm not sure if this is directly related or not, but the following program
produces the same output as the original (with the same problem):
subroutine print_int (i)
in
gcc dot gnu dot org
ReportedBy: me at kylehuey dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45157
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ gcc-10 --version
gcc (GCC
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
typedef unsigned int type __attribute__ ( ( vector_size ( 8 ) ) ) ;
type a , b;
void foo ( void ) {
type var
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
int x , y ;
int foo ( )
{
x = 0 ;
y = 0 ;
if (x != 0
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
int x = - 1 << 0 ;
int foo ()
{
switch ( x )
case - 1 << 0 :
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
extern void foo ( void ) ;
void bar ( double x )
{
if ( x == __builtin_speculation_safe_value
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
_Atomic double x ;
void foo ( void )
{
x = 1 ;
for ( int i = 0 ; i < 1 ; i ++ )
{
double y = x /
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
_Atomic float x = 5 ;
void foo ( int arg_0 )
{
void bar ( float arg_0 [ ( int ) ( x += 2
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
void foo ( void ) {
register int x asm ( "19&
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
extern struct S var ;
void foo ( )
{
asm volatile ( "" :
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
extern void (*x
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
int foo
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
int foo () {
x
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo ( )
{
extern __inline int bar ( ) { }
int baz ( ) { return bar
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
unsigned short * x = 0 ;
int foo ( void ) { * x = 0 ; }
int x [ ] = { 1 , 2 , 3 }
$ gcc-11 --version
++
Assignee: unassigned at gcc dot gnu.org
Reporter: c.de-claverie at pm dot me
Target Milestone: ---
Hello,
I would like to bring the following possible issue to your attention to make
sure the behaviour is expected :
https://stackoverflow.com/questions/63132693
To sum up the problem, a
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
extern char x[];
extern char y[];
extern char z[];
void foo ()
{
__atomic_exchange ( & x , & y , &
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo () {}
__attribute__ ( ( constructor ( foo ) ) ) void bar () { return 0
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void __builtin_abort ( int x
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo ( )
{
int x ;
int y[] = 1;
__builtin_va_arg ( x, int z
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: c.de-claverie at pm dot me
Target Milestone: ---
http://coliru.stacked-crooked.com/a/ad29e1a2281d762e with v10.2.0
May be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id
: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ gcc-9.2.0 -v
Using built-in specs.
COLLECT_GCC=/home/tom/Documents/gcc/9.2.0/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/tom/Documents/gcc/9.2.0/install/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto
201 - 300 of 726 matches
Mail list logo
