https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88970
Bug ID: 88970
Summary: ICE: verify_ssa failed (error: definition in block 2
follows the use)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Bug ID: 88968
Summary: [8/9 Regression] Stack overflow in gimplify_expr
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Bug ID: 88969
Summary: ICE in build_op_delete_call, at cp/call.c:6509
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #3 from Roman Lebedev ---
While there, any advice on how that is supposed to be rewritten?
Simply adding "shared(begin, len)" makes older gcc's unhappy
https://godbolt.org/z/gyZBR-
Only keeping "shared(begin, len)" (and dropping "defa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #2 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #1)
> It indeed changed, already in OpenMP 4.0 actually, but I've been long hoping
> that the change will be reverted in later OpenMP standards, in the end that
> is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
--- Comment #3 from Allan Jensen ---
No, it has to be a raw-string to be valid.
https://wandbox.org/permlink/I0yF3U3OXoH6LbIM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
Bug ID: 88967
Summary: [9 regression] openmp default(none) broken
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
--- Comment #2 from d25fe0be@ ---
It looks like this was (incorrectly, I assume) rejected since GCC 4.4.
https://wandbox.org/permlink/I0yF3U3OXoH6LbIM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #20 from Chris Elrod ---
To add a little more:
I used inline asm for direct access to the rsqrt instruction "vrsqrt14ps" in
Julia. Without adding a Newton step, the answers are wrong beyond just a couple
significant digits.
With the N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #1 from Anton Blanchard ---
Here's something more representative. Passing the address via an explicit
pointer makes the issue go away.
#include
#include
#define LOADU(p)vec_vsx_ld(0, (vector unsigned long *)(p))
static u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
--- Comment #2 from Bin Meng ---
(In reply to Dimitar Dimitrov from comment #1)
> The "linux" is a predefined macro:
>
> $ $ gcc -E -dM - #define linux 1
>
> Looks like by-design to me.
Indeed "linux" is a predefined macro. But why does str(l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
Dimitar Dimitrov changed:
What|Removed |Added
CC||dinuxbg at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #19 from Chris Elrod ---
To add a little more:
I used inline asm for direct access to the rsqrt instruction "vrsqrt14ps" in
Julia. Without adding a Newton step, the answers are wrong beyond just a couple
significant digits.
With the N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #4 from H.J. Lu ---
(In reply to Martin Sebor from comment #3)
> My question is about the change you are proposing. How do you expect g() to
> be called if the test case from comment #0 is modified for example as
> follows:
>
> vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86756
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
Bug ID: 88966
Summary: Indirect stringification of "linux" produces "1"
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317
--- Comment #11 from emsr at gcc dot gnu.org ---
The work for preprocessor/83063 may have impacted this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #17 from Alan Modra ---
> Is anything broken though?
Yes, as demonstrated by the testcase.
> If the libcall routines know they are called this way, all is fine.
They don't. libgcc functions are mostly C code that can make use of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #3 from Martin Sebor ---
My question is about the change you are proposing. How do you expect g() to be
called if the test case from comment #0 is modified for example as follows:
void f_plt(void);
void f_noplt(void) __attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
Bug ID: 88965
Summary: powerpc64le vector builtin hits ICE in verify_gimple
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88614
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88614
--- Comment #3 from Alan Modra ---
Author: amodra
Date: Tue Jan 22 02:29:47 2019
New Revision: 268135
URL: https://gcc.gnu.org/viewcvs?rev=268135&root=gcc&view=rev
Log:
[RS6000] PR88614, output_operand: invalid %z value
The direct cause of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Arseny Solokha changed:
What|Removed |Added
Known to work||7.3.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Bug ID: 88964
Summary: [8/9 Regression] ICE in wide_int_to_tree_1, at
tree.c:1561
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #20 from Segher Boessenkool ---
(In reply to Wilco from comment #19)
> (In reply to Segher Boessenkool from comment #18)
> > https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
>
> Thanks, I hadn't noticed that yet... I need to look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #19 from Segher Boessenkool ---
The pattern makes no sense at all for LE.
If LE,
(vec_concat:V2DF
(vec_select:DF
(match_operand:V2DF 1 "vfloat_operand" "wd,wa,wd,wa")
(parallel [(const_int 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927
--- Comment #5 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Jan 22 00:06:44 2019
New Revision: 268131
URL: https://gcc.gnu.org/viewcvs?rev=268131&root=gcc&view=rev
Log:
PR go/88927
runtime, internal/cpu: fix build for ARM GN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
--- Comment #20 from joseph at codesourcery dot com ---
r261797 removed all references to _ANSI_H_ from stddef.h, so this issue
can't be relevant after then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Bug ID: 88963
Summary: gcc generates terrible code for vectors of 64+ length
which are not natively supported
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
--- Comment #2 from Thomas Koenig ---
Created attachment 45486
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45486&action=edit
patch that appears to work
Plus a few additional test cases (it is necessary to split a few,
because internal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88949
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 21 22:33:52 2019
New Revision: 268127
URL: https://gcc.gnu.org/viewcvs?rev=268127&root=gcc&view=rev
Log:
PR c++/88949
* optimize.c (cxx_copy_decl): New function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #9 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #8)
> Created attachment 45485 [details]
> Proposed patch
Does this patch solves the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #8 from Vladimir Makarov ---
Created attachment 45485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45485&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88753
Dimitar Dimitrov changed:
What|Removed |Added
CC||dinuxbg at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88609
Dimitar Dimitrov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962
--- Comment #2 from Jiri Svoboda ---
I added the -fno-section-anchors option to both the compile and link
invocations but I am still getting the same result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #2 from H.J. Lu ---
(In reply to Martin Sebor from comment #1)
> I'm wondering if noplt is meant to be a property of the function pointer or
> that of its type?
>
> Either way, what should happen in cases when a noplt pointer is assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962
--- Comment #1 from Andrew Pinski ---
What happens if you use -fno-section-anchors option? My bet is the section
anchor is setting the bias for the static variables to be 32k off of the
center.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962
Bug ID: 88962
Summary: Invalid/inconsistent PowerPC TLS variable access
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #8 from Sergei Trofimovich ---
(In reply to Martin Liška from comment #3)
> Confirmed, started with r231498.
That was really fast!
Minor comment: 'git tag' says that revision was added before gcc-6.1.0.
Running test locally says 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961
Bug ID: 88961
Summary: valgrind error in resolve_ref
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #19 from Wilco ---
(In reply to Segher Boessenkool from comment #18)
> https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
Thanks, I hadn't noticed that yet... I need to look at it in more detail, but
are you saying that combine no long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #18 from Jakub Jelinek ---
The comment on the define_insn_and_split says:
;; Combiner patterns with the vector reduction patterns that knows we can get
;; to the top element of the V2DF array without doing an extract.
So, the question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #17 from Bill Schmidt ---
Actually I *think* the *vsx_reduc__v4sf_scalar code is probably
okay. This is all being done with insns that should leave the reduction result
in the right-hand element of the register (element 3 for BE, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #16 from Bill Schmidt ---
(In reply to Jakub Jelinek from comment #13)
> So, both the following patches should fix it IMHO, but no idea which one if
> any is right.
> With
> --- gcc/config/rs6000/vsx.md.jj 2019-01-01 12:37:44.30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935
Jason Merrill changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935
--- Comment #4 from Jason Merrill ---
*** Bug 87893 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87893
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935
Jason Merrill changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88616
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87770
--- Comment #5 from Konrad Dabrowski ---
(In reply to Alexandre Oliva from comment #4)
> Created attachment 45448 [details]
> Candidate patch
I don't know enough about gcc to assess whether this is the "correct" solution,
but I can confirm that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87893
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938
--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jan 21 20:14:40 2019
New Revision: 268123
URL: https://gcc.gnu.org/viewcvs?rev=268123&root=gcc&view=rev
Log:
PR target/88938
* config/i386/i386.c (ix86_expand_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850
--- Comment #6 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #5)
> So yeah it seems that there are three issues here:
>
> 1) We should probably have an r -> r alternative for *neon_mov.
> 2) The costs are now flipped from w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88901
--- Comment #5 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88960
--- Comment #1 from Nathan Weeks ---
Note that GET_TEAM() itself is currently broken in gfortran (pr88154).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88901
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 21 19:53:04 2019
New Revision: 268122
URL: https://gcc.gnu.org/viewcvs?rev=268122&root=gcc&view=rev
Log:
PR sanitizer/88901
* typeck.c (cp_build_binary_op): Don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88956
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88960
Bug ID: 88960
Summary: [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM,
and CURRENT_TEAM
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #18 from Segher Boessenkool ---
https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88293
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88959
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86205
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
--- Comment #3 from Jakub Jelinek ---
Can't reproduce with a cross-compiler, neither current 8.2.1 with -O3
-march=zEC12 nor -O3 -march=z14, nor with current trunk and the same options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88949
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
--- Comment #1 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #0)
> Adding a dummy __int128 field makes GCC accept the code (but such workaround
> won't work for wider vectors, or on 32-bit).
But this causes the union to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88916
--- Comment #2 from Wojciech Mula ---
(In reply to Richard Biener from comment #1)
> Confirmed.
The first case is OK, but the second (for `both_nonzero`) is obviously wrong.
Sorry for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #17 from Wilco ---
(In reply to Vladimir Makarov from comment #14)
> I've checked cvtf_1.c generated code and I don't see additional fmov
> anymore. I guess it was fixed by an ira-costs.c change (a special
> consideration of moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #23 from Harald van Dijk ---
(In reply to Eric Gallager from comment #22)
> (In reply to Harald van Dijk from comment #21)
> > Since -Wjump-misses-init triggers too often for commonly used C patterns,
> > I do not think it is appropri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88847
--- Comment #3 from Tamar Christina ---
right, so it seems this is an SVE issue and doesn't have much to do with stack
protector.
The issue is that aarch64_sve_struct_memory_operand_p doesn't take into account
whether it is before or after reloa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88959
--- Comment #1 from Daniel Fruzynski ---
I have found that this extra xor is not added when compiling with -O3
-march=sandybridge or -O3 -march=ivydybridge. However with -O3
-march=sandybridge/ivydybridge -mbmi it is added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
Eric Gallager changed:
What|Removed |Added
Summary|diagnostics: Please add |diagnostics: Have
|war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88959
Bug ID: 88959
Summary: Unnecessary xor before bsf/tzcnt
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958
--- Comment #1 from G. Steinmetz ---
$ gdc-9-20190120 -c z1.d -O0
$
$ gdc-9-20190120 -c z1.d -O1
during GIMPLE pass: fre
In function 'h':
d21: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:976
0xce83a5 copy_referen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958
Bug ID: 88958
Summary: ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #16 from Segher Boessenkool ---
(In reply to Wilco from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > Before the change combine forwarded all argument (etc.) hard registers
> > wherever
> > it could, doing part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957
Bug ID: 88957
Summary: ICE: Segmentation fault in tree_could_trap_p, at
tree-eh.c:2672
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88956
Bug ID: 88956
Summary: [9 Regression] ICE: Floating point exception
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88949
--- Comment #1 from Jakub Jelinek ---
As it works with -DMETHOD -fopenmp, but doesn't with -fopenmp, it must be the
cdtor copying in the FE that breaks this.
struct A {
int a;
A (int x) : a (x)
#ifdef METHOD
{}
void foo ()
#endif
{
#pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #3 from Tim Shen ---
Thanks for reporting Tomalak.
Yes, I agree that "match from the first character" should be expressable in the
public interface, preferrably regex_search() with "^...". In fact, internally
regex_search is implemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
--- Comment #2 from Jan Kossmann ---
Created attachment 45483
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45483&action=edit
Preprocessed file and minimal cpp example
This archive contains the preprocessed *.ii file, a .cpp and .hpp file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
Bug ID: 88955
Summary: transparent_union for vector types not accepted
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
Andrew Pinski changed:
What|Removed |Added
Target||powerpc-*-*
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #3 from Christopher Leonard
---
I understand it has to split it, the problem is that %0 defaults to the
register holding the most-significant part of the integer. Is this really the
desired behavior?
1 - 100 of 233 matches
Mail list logo
