https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
bin.cheng amker.cheng at gmail dot com changed:
What|Removed |Added
CC||amker.cheng at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #6 from Jeffrey A. Law law at redhat dot com ---
It's late and I need to catch some zzzs. But as I hinted in my prior update, I
think we may chasing something latent. I would recommend looking very closely
at r204497, which my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
More eyes never hurt :-) This pair is going to bed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
reasoning why gcc considers it valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #6 from Sven C. Dack sven.c.dack at virginmedia dot com ---
It seems the problem is caused by the use of the jobserver. Changing
bootstrap-lto.mk from:
...
STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack sven.c.dack at virginmedia dot com changed:
What|Removed |Added
Attachment #33285|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Sven C. Dack from comment #7)
Created attachment 33299 [details]
Removes the use of the jobserver from bootstrap-lto.mk
The patch changes bootstrap-lto.mk to use a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #11 from David Krauss potswa at mac dot com ---
On 2014–08–12, at 3:10 PM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
wrote:
Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
reasoning why gcc considers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 12 Aug 2014, trippels at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #6)
It's late and I need to catch some zzzs. But as I hinted in my prior update,
I think we may chasing something latent. I would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #11 from Venkataramanan venkataramanan.kumar at amd dot com ---
I am also trying to fix LTO bootstrap compare failure in Aarch64.
Bootstrap compare failure is not occurring in GCC FSF trunk (tested on aarch64
as well as x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
--- Comment #7 from Yuri Rumyantsev ysrumyan at gmail dot com ---
Please ignore my previous comment - if we insert nullifying of destination
register before each popcnt (and lzcnt) performance will restore:
original test results:
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
And with:
--- sched-deps.c(revision 207605)
+++ sched-deps.c(working copy)
@@ -3034,6 +3034,21 @@ sched_analyze_insn (struct deps_desc *de
|| (NONJUMP_INSN_P (insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104
Bug ID: 62104
Summary: [4.10 Regression] ICE: in
update_visibility_by_resolution_info, at
ipa-visibility.c:403
Product: gcc
Version: 4.10.0
Status:
like -lgcc and -lc are placed correctly maybe the
-l*san can be moved too?
I used a gcc built from recent SVN head on Ubuntu 14.04 amd64.
/tmp/jtaylor $ gcc-4.10 --version
gcc (GCC) 4.10.0 20140812 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, so there is one thing that changed (but only very recently) on trunk which
is improved hashing of SCCs and thus more consistent ordering.
Especially I'm talking about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106
Bug ID: 62106
Summary: Adding a scalar variable to an array constructor gives
wrong result
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106
--- Comment #1 from Martien Hulsen m.a.hulsen at tue dot nl ---
It only shows up using optimisation, i.e. -On, with n=1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 /tmp % wget trippelsdorf.de/testcase.tar.bz2
--2014-08-12 12:07:24-- http://trippelsdorf.de/testcase.tar.bz2
Resolving trippelsdorf.de... 194.117.254.50
Connecting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #12)
Ok, so there is one thing that changed (but only very recently) on trunk
which
is improved hashing of SCCs and thus more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #12 from amker at gcc dot gnu.org ---
Hi,
I can reproduce the exact mis-scheduled instruction issue as in Jakub's comment
with/without the ivopt patch (204497). Turns out gcc chooses candidate like
{K512, 128}_loop with the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
--- Comment #8 from finis at in dot tum.de ---
@Yuri: Note however, that the result of your fixed u32 version seems to be
wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #14 from Venkataramanan venkataramanan.kumar at amd dot com ---
(In reply to Sven C. Dack from comment #6)
It seems the problem is caused by the use of the jobserver. Changing
bootstrap-lto.mk from:
...
STAGE2_CFLAGS +=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
Just verified the trunk and it is the same thing there, also sched2 generating:
al %r3,252(%r8)
ahi %r8,128
alc %r2,120(%r8)
where the first insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #15 from Sven C. Dack sven.c.dack at virginmedia dot com ---
(In reply to Venkataramanan from comment #14)
...
I tried addding to stage2/3 the flags -flto=1 -flto-partition=none instead
of jobserver in bootstrap-lto.mk and spawned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
--- Comment #9 from Yuri Rumyantsev ysrumyan at gmail dot com ---
This is not u32 version but u64. The first loop (u32) version looks like:
.L23:
leal1(%rdx), %ecx
xorq%rax, %rax
popcntq(%rbx,%rax,8), %rax
leal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #2 from Peter A. Bigot pab at pabigot dot com ---
Thanks. The compiler and libstdc++ are built using Yocto's standard recipe for
the beaglebone. Obviously there's something wrong with it; what that would be
is not obvious and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61373
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107
Bug ID: 62107
Summary: libgomp.fortran/target2.f90 FAIL while compiling for
OpenMP 4.0 offload target
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||bernds at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
It might be obvious in the output of 'gcc -v'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60281
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, what about this completely untested fix? Unfortunately the scheduler
change has been committed with no testcases. I guess I'll do a
bootstrap/regtest with some printout where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962
--- Comment #1 from Kirill Yukhin kyukhin at gcc dot gnu.org ---
Author: kyukhin
Date: Tue Aug 12 12:27:41 2014
New Revision: 213858
URL: https://gcc.gnu.org/viewcvs?rev=213858root=gccview=rev
Log:
PR other/61962
gcc/c-family/
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962
--- Comment #2 from Kirill Yukhin kyukhin at gcc dot gnu.org ---
Author: kyukhin
Date: Tue Aug 12 12:33:06 2014
New Revision: 213859
URL: https://gcc.gnu.org/viewcvs?rev=213859root=gccview=rev
Log:
PR other/61962
gcc/c-family/
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #4 from Peter A. Bigot pab at pabigot dot com ---
It's not obvious to me:
beaglebone[98]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/gcc/arm-poky-linux-gnueabi/4.9.1/lto-wrapper
Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #16 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, so what happens is that for build/genconfig.o we in one case write
a STRING_CST with a const char[7] with itself as main-variant and in
the other case with char[7] as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
--- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Created attachment 33300
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33300action=edit
Patch under testing.
Embarassing patch to fix the issue. Currently being tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61373
--- Comment #2 from John Breitenbach breiten at lexmark dot com ---
Created attachment 33301
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33301action=edit
siphash24.i
sorry for forgetting this attachment in the original report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613
--- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to David Krauss from comment #6)
I'd like to take it 100% but the testsuite isn't working on my system. The
patch is small enough and unobscure enough that it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #9 from Mike Frysinger vapier at gentoo dot org ---
i've verified that 4.8.0 4.9.1 fail as well :/
binutils 2.24 doesn't help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #16 from Jeffrey A. Law law at redhat dot com ---
In reference to c#12. I think the ivopts changes are just setting up the
situation that is mis-handled later. I'd gotten as far as seeing the +128
increment moving in the scheduler,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 12 Aug 2014, potswa at mac dot com wrote:
each instance of a ## preprocessing token in the replacement list (not
from an argument) is deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098
--- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Author: ramana
Date: Tue Aug 12 14:32:07 2014
New Revision: 213861
URL: https://gcc.gnu.org/viewcvs?rev=213861root=gccview=rev
Log:
Fix PR target/62098
2014-08-12 Ramana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Also, in the case of just two consecutive ##, with a placemarker either
side, I think however you read it the concatenations are currently valid
and you end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61413
--- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Author: ramana
Date: Tue Aug 12 14:59:23 2014
New Revision: 213864
URL: https://gcc.gnu.org/viewcvs?rev=213864root=gccview=rev
Log:
Fix PR target/61413
2014-08-12 Ramana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Note that while
program testerprog
use testmod
Type(A) :: Me
Me%y=2
print *, Me%x, Me%y
end program
gives at run time
1 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62087
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62108
Bug ID: 62108
Summary: Resolution of mismatched __attribute__ ((__section__
())) changes between 4.9 and 4.10.
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094
--- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Tue, Aug 12, 2014 at 03:40:06PM +, dominiq at lps dot ens.fr wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094
Dominique d'Humieres dominiq at lps dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62108
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||jgreenhalgh at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078
--- Comment #10 from wbrana wbrana at gmail dot com ---
there is difference also with O2 and branch 4.9
size in bytes
57199 -O2
55222 -O2 -flto
60681 -O2 -finline-functions
75301 -O2 -flto -finline-functions
67083 -O2 -flto -finline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61274
--- Comment #2 from wbrana wbrana at gmail dot com ---
gcc should probably support new level -O4 which will optimize for benchmarks,
which will equal to current -O3
-O3 and bellow will optimize for applications with saner --param values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
Bug ID: 62109
Summary: __gthr_i486_lock_cmp_xchg missing clobber
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Component|target |c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
Bug ID: 62110
Summary: Attempting to use template conversion operator in a
contextual conversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
Bug ID: 62111
Summary: ICE when building Linux kernel for sh64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com ---
The following command line is sufficient to reproduce the error:
sh64-linux-gnu-gcc -m5-64media-nofpu -ml -O2 -S -o testcase.o testcase.i
Adding -v to the command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com ---
The binutils is based on the 2.24 branch, git commit
cab6c3ee9785f072a373afe31253df0451db93cf and was built targeting
sh64-linux-elf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
Bug ID: 62112
Summary: Optimize out malloc when block is unused or write-only
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62113
Bug ID: 62113
Summary: [graphite] ICE using -floop-parallelize-all
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114
Bug ID: 62114
Summary: [graphite] ICE using -floop-parallelize-all and
-ffast-math
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Target||sh*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #4 from dhowells at redhat dot com dhowells at redhat dot com ---
The compiler is gcc-4.9.1, dated 20140717, svnrev 212747.
One patch is applied - see bug 61844.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
N3323 is not addressing a DR, so is not part of C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
Main issue here is that DSE only applies to assignments and not function calls
like memcpy (there must be a few dups somewhere), so we never remove memcpy,
even if we call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
--- Comment #2 from Zack Weinberg zackw at panix dot com ---
I observe that the `memcpy` does get lowered to inline code. Is it just a
phase-ordering problem that we then don't detect the stores as dead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Tue Aug 12 21:24:40 2014
New Revision: 213887
URL: https://gcc.gnu.org/viewcvs?rev=213887root=gccview=rev
Log:
PR target/62025
* sched-deps.c (find_inc):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Tue Aug 12 22:03:37 2014
New Revision: 213888
URL: https://gcc.gnu.org/viewcvs?rev=213888root=gccview=rev
Log:
PR target/62025
* sched-deps.c (find_inc):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
--- Comment #38 from Steve Ellcey sje at gcc dot gnu.org ---
FYI: I am testing a new patch for this that adds a new pass to do this
optimization. See https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01228.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #23 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #22)
This is a target independent issue. Clang++ skips empty struct argument
and g++ passes it. Skip empty struct argument requires middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62085
--- Comment #3 from James Lyon jameslyon0 at gmail dot com ---
Thanks for looking! Unfortunately I don't have access to EDG. I have dug
through the standard and it seems my understanding of SFINAE was (is) a
bit lacking and GCC is indeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62115
Bug ID: 62115
Summary: [4.10 Regression] ICE with invalid default argument
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62115
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
TC rs2740 at gmail dot com changed:
What|Removed |Added
CC||rs2740 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54773
--- Comment #2 from chihin ko chihin.ko at oracle dot com ---
g++ 4.8.1 on Linux fixed the problem, but problem still exists in g++ 4.8.1 on
solaris.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116
Bug ID: 62116
Summary: Allowing redeclaration of global variable x using ::x
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
bin.cheng amker.cheng at gmail dot com changed:
What|Removed |Added
CC||amker.cheng at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #24 from vagran vagran.ast at gmail dot com ---
Just to be on a safe side, please, also do not forget that empty struct (or
class) is really zero in the case when another structure (or class) is derived
from it. For example, such test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024
--- Comment #2 from Amanieu d'Antras amanieu at gmail dot com ---
A similar error happens when trying to use the result of
__atomic_always_lock_free as the size of an array:
int array[__atomic_always_lock_free(sizeof(int), 0)];
test.c:1:5:
93 matches
Mail list logo
