: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo ( )
{
void bar() char str[({ void func(){ int x; } )];
}
My gcc-8's snapshot version is gcc-8-20191101
$ gcc-snapshot8 -v
Using bui
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo ( )
{
float x ;
asm ( "" : : "pir" ( x ) ) ;
}
My gcc snapshot version
$ gc
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
int foo ( void ) ;
int __attribute__ ( ( returns_twice ) ) bar ( void ) ;
void baz ( )
{
int x ;
if ( x > 10 )
exit ( 0 ) ;
retur
ty: 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 ( void )
{
register int x asm ( "19" ) ;
int y = x;
}
My command li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92469
--- Comment #2 from John X ---
Yes, you are right. If we change "19" to "20", it still ICEs for older versions
of GCC.
$ cat test2.c
void foo ( void )
{
register int x asm ( "20" ) ;
int y = x;
}
$ gcc-snapshot8 --version
gcc (G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92469
--- Comment #3 from John X ---
Yes, you are right. If we change "19" to "20", it still ICEs for older versions
of GCC.
$ cat test2.c
void foo ( void )
{
register int x asm ( "20" ) ;
int y = x;
}
$ gcc-snapshot8 --version
gcc (G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92469
--- Comment #4 from John X ---
Sorry, I submitted the same comment twice due to the bad network environment. I
don't know how to delete the duplicate one. Any one could help me?
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void bar ( char * a , unsigned int b )
{
static char const array[] = "STRING" ;
__builtin_strcpy (a , &array[b == 0] );
}
$ gcc-snapshot7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92478
--- Comment #2 from John X ---
(In reply to Jakub Jelinek from comment #1)
> Started to ICE with r247622, got fixed with r262742.
Thanks~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92478
--- Comment #3 from John X ---
(In reply to Jakub Jelinek from comment #1)
> Started to ICE with r247622, got fixed with r262742.
Would the ICE in gcc-8 be fixed?
-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo ( )
{
char bar ;
if ( bar )
{
volatile int * bar = & bar ;
__asm__ ( "cmp $1, %1" : "=@ccng
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat 0.c
int global ;
void foo() ;
__attribute__((returns_twice)) int bar() ;
void baz(int, int);
void main ( )
{
int x;
for ( ; ; )
foo
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
static void __attribute__ ( ( weakref ( "bar" ) ) ) foo ( void ) { }
extern void
: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo ( void ) { }
static void bar ( void )
{
inline void foo ( void ) ;
if ( foo == 0
: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
extern long unsigned int sub_0 ( const char * ) ;
extern void * sub_1 ( long unsigned int ) ;
extern int var_0 ;
void * var_1 = & v
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: simonas+gcc.gnu.org at kazlauskas dot me
Target Milestone: ---
I found out a case where gcc does not honour the Windows’ x64 calling
convention even if explicitly asked to use this ABI. Consider a function as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911
--- Comment #4 from 鍾 ---
(In reply to Eric Botcazou from comment #3)
> > I use the administrator user and administrator permissions in Windows host,
> > so, normally I use the same permission map to root permissions in Cygwin
> > host.
>
> Plea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911
--- Comment #6 from 鍾 ---
(In reply to Eric Botcazou from comment #5)
> > -rw-r--r-- 1 Administrator None 1.7K 六月 14 00:12 a-assert.ali
> > -rw-r--r-- 1 Administrator None 16K 六月 14 00:12 a-btgbso.ali
> > -rw-r--r-- 1 Administrator None 2.7K 六月
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at bluematt dot me
Target Milestone: ---
Without bringing up the deadly "warn when using arrays in function
declarations" quagmire, if you are converting an array of o
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mail+gccbugs at svenpeter dot me
Target Milestone: ---
Created attachment 37065
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37065&action=edit
testcase to reproduce the bug
Enabling O3 runs only a part
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: heresy-me at hotmail dot com
Target Milestone: ---
There are many occasion that to do some compile-time check if we need. For
example, I write my own sqrt function that it may check its parameter should
greater than or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71592
--- Comment #2 from 鍾 ---
(In reply to Jakub Jelinek from comment #1)
> You can't use such static_assert this way in C++, unless the function is
> constexpr, nor in C (always), so guess you are proposing something
> completely different (like, if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71592
鍾 changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
--- Comment #5 from 鍾 ---
full_assertion_decl
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: heresy-me at hotmail dot com
Target Milestone: ---
Created attachment 38832
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38832&action=edit
libfsqlite-full
I am wrapping the libsqlite3-dev for Fortran.
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71764
--- Comment #1 from 鍾 ---
$ uname -a
CYGWIN_NT-6.1 LLVM 2.5.2(0.297/5/3) 2016-06-23 14:29 x86_64 Cygwin
$ gcc -v
使用内建 specs。
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/lto-wrapper.exe
目标：x86_64-pc-cygwin
配置为：/cygdrive
ty: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: heresy-me at hotmail dot com
Target Milestone: ---
with Ada.Text_IO;
procedure Hello is
begin
Ada.Text_IO.Put_Line ("Hello world!");
end Hello;
$ g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911
--- Comment #2 from 鍾 ---
(In reply to Eric Botcazou from comment #1)
> How was the compiler configured? Which permissions have the ALI files?
使用内建 specs。
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/lto-wrapper.exe
目
--- Comment #7 from matt at galloway dot me dot uk 2007-03-18 01:06 ---
Same problem for me with gcc-4.0.1. Is this going to get fixed or is it correct
behaviour and the code needs some sort of codeword to tell the compiler that
func2 is a template?
--
matt at galloway dot me dot uk
--- Comment #9 from matt at galloway dot me dot uk 2007-03-18 11:01 ---
(In reply to comment #8)
> The work around is doing:
> get_a().template func2 ();
>
>
> Which tells the compiler for sure func2 is a template.
>
Thanks, yeh I figured that out just now
--- Additional Comments From mlists at juma dot me dot uk 2005-04-12 20:01
---
(In reply to comment #11)
> CC'ed.
--
What|Removed |Added
--
What|Removed |Added
CC||mlists at juma dot me dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stdin at stdin dot me dot uk
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35884
cc.gnu.org/bugs.html> for instructions.
--
Summary: Segmentation fault when compiling arith1.c of Pari/GP
2.3.3/2.3.4 with -O3
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Michael dot Finken at me dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39277
--- Comment #1 from Michael dot Finken at me dot com 2009-02-23 16:57
---
Created an attachment (id=17350)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17350&action=view)
This is the log of the compile command
This is the complete output of the compile command, when r
--- Comment #2 from Michael dot Finken at me dot com 2009-02-23 16:58
---
Created an attachment (id=17351)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17351&action=view)
The intermediate file after pre-processing
The magic source file...
--
http://gcc.gnu.org/b
--- Comment #3 from Michael dot Finken at me dot com 2009-02-23 16:58
---
Created an attachment (id=17352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17352&action=view)
The assembler source, created upto the crash.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39277
--- Comment #4 from Michael dot Finken at me dot com 2009-02-23 17:01
---
This happens with gcc 4.3.2 as well.
I compiled gcc 4.3.3 today, hoping that the problem would no longer appear.
--
Michael dot Finken at me dot com changed:
What|Removed
l:
fs/timerfd.c:105:1: error: unrecognizable insn:
(insn 44 43 45 5 fs/timerfd.c:94 (set (reg:SI 68)
(subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
(const_int 64 [0x40])) [0 S8 A64]) 4)) -1 (nil))
fs/timerfd.c:105:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
This kernel compiles fine with gcc 3.4.0 and the lm32 patch which was published
on the GCC mailing list.
Removing "-O2" from the command line allows gcc to pass the ICE and compile
successfully.
--
Summary: ICE when building Linux kernel 2.6.34-rc4
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philpem at philpem dot me dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43805
--- Comment #1 from philpem at philpem dot me dot uk 2010-04-19 20:27
---
Created an attachment (id=20426)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20426&action=view)
timerfd intermediate file
.i file, requested per bug reporting guidelines
--
http://gcc.
--- Comment #2 from philpem at philpem dot me dot uk 2010-04-19 20:33
---
Admittedly removing -O2 does fix the ICE in this file, however a different
source file (mm/filemap.c) causes a gcc ICE when it isn't built with -O2:
mm/filemap.c: In function do_generic_file_read:
mm/file
--- Comment #4 from philpem at philpem dot me dot uk 2010-04-22 21:28
---
I've just bisected the source tree with "svn-bisect" -- starting at rev 154096
(the first rev with lm32 support), ending at 158339 (gcc 4.5.0 release).
Turns out the bug was introduced in or befor
--
What|Removed |Added
CC||mlists at juma dot me dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: remko dot scharroo at me dot com
GCC build triplet: x86_64-apple-darwin10.3.0
GCC host triplet: x86_64-apple-darwin10.3.0
GCC target triplet: x86_64-apple-darwin10.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
--- Comment #3 from remko dot scharroo at me dot com 2010-06-11 18:22
---
I fully agree that the second "deallocate (p2, stat=ios)" is a violation.
That is the actual intend of this program.
You know, this is not arbitrary code. You can often have multiple pointers
p
--- Comment #2 from stdin at stdin dot me dot uk 2008-04-11 03:36 ---
You define __need_size_t when you want to pull in the definition of size_t but
not other typedefs/functions. It's the standard way to get the size_t type.
--
stdin at stdin dot me dot uk changed:
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fmuldoo at me dot lsu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36167
--- Comment #1 from fmuldoo at me dot lsu dot edu 2008-05-07 09:32 ---
Created an attachment (id=15589)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15589&action=view)
Very small code example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36167
--- Comment #4 from fmuldoo at me dot lsu dot edu 2008-05-20 20:40 ---
Subject: Re: ICE in gfc_conv_descriptor_dimension, at
fortran/trans-array.c:242
Hi Paul,
Thanks for the work-around. I now have got my code built using
gfortran.
Frank
On Sat, 2008-05-17 at 16:20
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fmuldoo at me dot lsu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
--- Comment #1 from fmuldoo at me dot lsu dot edu 2008-06-20 11:46 ---
Created an attachment (id=15794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15794&action=view)
very short example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
--- Comment #3 from fmuldoo at me dot lsu dot edu 2008-06-20 12:32 ---
Subject: Re: Namelist I/O error: Bogus "Cannot match
namelist object"
Hello,
I am not sure what is meant by "regression". Am I correct in assuming
that you do not regard it as an er
--- Comment #7 from fmuldoo at me dot lsu dot edu 2008-06-21 08:47 ---
Subject: Re: Namelist I/O error: Bogus "Cannot match
namelist object"
Hello Burnus,
Thanks for explaining that to me. It is clear now.
Regards,
Frank
On Sat, 2008-06-21 at 08:32 +, burnus
--- Comment #13 from fmuldoo at me dot lsu dot edu 2008-07-22 22:54 ---
Subject: Re: Namelist I/O error: Bogus "Cannot match
namelist object"
Great, and thanks very much. I'm very glad you found it as it is the
only thing preventing me from using gfortran with
This bug applies at least to gcc version 4.0.3 and the current CVS 4.2.0
20061103. The assembly extracts included below were produced by gcc 4.2.0; the
gcc 4.0.3 extracts are analogous with respect to this problem but are different
in some respects. My particular host is an intel pentium4 xenon.
W
--- Comment #16 from james dot me at gmail dot com 2006-11-04 16:26 ---
I applied Richard Guenther's patch to my own 4.2 svn branch to get this fixed
locally, but the change had no effect. I am a little puzzled by this, because
what I can discern from the discussion and comment
NFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at flash-gordon dot me dot uk
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27534
--- Comment #2 from bernard at brenda-arkle dot me dot uk 2008-12-13 23:53
---
I'm not sure what 'now' means. It's still true for release 4.3.2!
I'm prepared to test with the live sources, but do you want me to?
Do you believe that the problem has been underst
bunwind' '--with-system-zlib'
'--enable-bootstrap'
The CPU is an Athlon64 X2.
--
Summary: ICE while building libgfortran (gcc bootstrap)
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528
--- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-12-14 20:15
---
Created an attachment (id=16908)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16908&action=view)
First source file in test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528
--- Comment #2 from bernard at brenda-arkle dot me dot uk 2008-12-14 20:16
---
Created an attachment (id=16909)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16909&action=view)
Second source-file of test case (2/2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528
--- Comment #5 from bernard at brenda-arkle dot me dot uk 2008-12-14 20:30
---
Responding to comment #3: *Ahem*. I tried with today's live sources
(revision 142751). I got as far as building libgfortran in stage 3, and
*bang*. Bug 35828, which see. It's not obviously rela
--- Comment #4 from bernard at brenda-arkle dot me dot uk 2008-12-18 18:45
---
Is that official? Do you want to maintain a list of documented gcc
options which unlikely ever to work, for the benefit of the rest of
us?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528
--- Comment #7 from bernard at brenda-arkle dot me dot uk 2008-12-18 18:54
---
Sorry about the bug-number error. 38528 was what I meant.
Andrew Pinski's reply there suggests that --enable-intermodule
is simply doomed anyway.
(a) Since submitting the original bug report I corr
--- Comment #3 from bernard at brenda-arkle dot me dot uk 2008-10-17 21:08
---
I've seen this with 4.3.1 and 4.3.2 official releases with (as it happens)
athlon-64 again (but 32-bit Linux). But then I also saw it with 4.3.1
on a pure Pentium4 system, so I don't think it&#
7; 'CFLAGS=-Wall -march=athlon64-sse3'
'CXXFLAGS=-Wall -march=athlon64-sse3'
--
Summary: gfortran build fails in stage 3 bootstrap with --enable-
intermodule
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
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=37865
(the 2.9GHz flavour, not the 2.8GHz flavour).
My binutils are from release 2.18, built with an unpatched gcc-4.3.1 .
--
Summary: ICE in extract_bit_field_1
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
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=37870
(the 2.9GHz flavour, not the 2.8GHz flavour).
My binutils are from release 2.18, built with an unpatched gcc-4.3.1 .
--
Summary: ICE in extract_bit_field_1
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
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=37872
--- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-10-19 13:57
---
*** This bug has been marked as a duplicate of 37870 ***
--
bernard at brenda-arkle dot me dot uk changed:
What|Removed |Added
--- Comment #2 from bernard at brenda-arkle dot me dot uk 2008-10-19 13:57
---
*** Bug 37872 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37870
(the 2.9GHz flavour, not the 2.8GHz flavour).
My binutils are from release 2.18, built with an unpatched gcc-4.3.1 .
--
Summary: ICE in extract_bit_field_1
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
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=37873
--- Comment #1 from bernard at brenda-arkle dot me dot uk 2008-10-19 14:39
---
I'm really sorry - requesting the form after network problems apparently
submits it again! Is this itself a bug in the UI?
*** This bug has been marked as a duplicate of 37870 ***
--
bernard at b
--- Comment #3 from bernard at brenda-arkle dot me dot uk 2008-10-19 14:39
---
*** Bug 37873 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37870
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
If configure-time ld does not support SHF_GNU_RETAIN, __has_attribute(retain)
may be true while using it will cause a warning.
% cat x.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99587
--- Comment #6 from Fangrui Song ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Florian Weimer from comment #4)
> > For retain, something along these lines might work:
> >
> > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
to drop reliance on ld's default linker script
.init_array:
{
PROVIDE_HIDDEN (__init_array_start = .);
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424#c8
% echo 'int main() {}' > a.c
% clang --t
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Per object file .fini_array.00100 wastes space. __gcov_exit can be called in
libgcov. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98038
--- Comment #1 from Alisdair Meredith ---
The following example code gives an internal compiler error, I suspect due to
the invalid attempt to call `operator()` recursively on the lambda object. Use
the -std=c++20 language flag:
#include
#incl
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
#include
int main() {
puts("meow");
}
% gcc -mcmodel=large -fno-plt -O1 -S a.c -fpic -o - -O2
-fno-as
rmal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
After "x86-64: Optimize access to globals in PIE with copy reloc", GCC x86-64
asks the assembler to produce an R_X86_64_PC32 for an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #2 from Fangrui Song ---
Note: -fdirect-access-external-data is architecture-independent. For example,
currently Clang on aarch64 can perform the following optimization:
// clang -target aarch64 -fPIE -O3
adrpx8, :got:var
ldr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111
Tom de Geus changed:
What|Removed |Added
CC||tom at geus dot me
--- Comment #6 from
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at hussam dot eu.org
Target Milestone: ---
this worked in the 20201120 snapshot and broke in the 20201127 snapshot.
[CXX] vcl/workben/vcldemo.cxx
/home/hussam/cache/system/libreoffice/src/libreoffice/vcl/workben
erity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcov used _J. C. Tiernan, An Efficient Search Algorithm to Find the Eleme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
--- Comment #10 from Fangrui Song ---
Note: the section key is not just (name, group name "G"). It is a quadruple:
(name, group name "G", linked-to "o", unique ID)
Keeping just name works for the simplest case.
If GCC decides to support PR95095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #3 from Fangrui Song ---
Are you happy with the option name -f[no-]direct-access-external-data ?
https://reviews.llvm.org/D92633 is what I want to add to Clang.
I want GCC and Clang to use the same option names...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195
--- Comment #10 from Fangrui Song ---
(In reply to Jakub Jelinek from comment #9)
> I believe this broke building the kernel, see
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561974.html
> for details.
For
> ld: .init.data has both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #7 from
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: GCCBugzilla at DRHouck dot me
Target Milestone: ---
Created attachment 49275
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49275&action=edit
Tarball of original file (.cpp), preprocessed file (.ii), and c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #5 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Fangrui Song from comment #3)
> > Are you happy with the option name -f[no-]direct-access-external-data ?
>
> Not at all, no :-(
>
> The name d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #7 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #6)
> (In reply to Fangrui Song from comment #5)
> > Please read my first comment why copy relocs is a bad name.
>
> Since I reply to some of that (namely, your ar
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
Created attachment 49962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49962&action=edit
bug test file
a, compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98673
--- Comment #2 from jojo ---
(In reply to Richard Biener from comment #1)
> The analysis sounds a bit confused. What is the transform that DOM cannot
> do after the transform that FRE does? There's some older bug about
> out-of-SSA
> coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #3 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #2)
> Can't we use ".text%name" for -ffunction-sections, like we did originally,
> in 1996? See cf4403481dd6. This does not conflict with other section
> names, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98673
--- Comment #3 from jojo ---
(In reply to jojo from comment #2)
> (In reply to Richard Biener from comment #1)
> > The analysis sounds a bit confused. What is the transform that DOM cannot
> > do after the transform that FRE does? There's some
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
gcc/testsuite/g++.dg/eh/forced3.C says forced unwinding calls std::unexpected
going through a throw() function.
gcc/testsuite/g++.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #5 from Fangrui Song ---
Linux kernel
include/asm-generic/vmlinux.lds.h currently has
#define TEXT_TEXT \
ALIGN_FUNCTION(); \
301 - 400 of 722 matches
Mail list logo
