Tests were executed in the remaining systems.
I created a jira card with the details about the tests
https://warthogs.atlassian.net/jira/core/projects/ST/board?selectedIssue=ST-1986
The failing tests for jammy and focal are test issues (in 2.62 branch).
The same for the errors in Mantic (those
se inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.
On Wed, May 1, 2024 at 8:49 AM christian.marinelli--- via sr-users
It's also worth noting that ifupdown is being slowly deprecated in
favour of more modern solutions, like networkd-dispatcher.
Having said that, I tried placing a test script inside /etc/networkd-
dispatcher/routable.d/, but it still doesn't work.
--
You received this bug notification because
On Wednesday, May 01 2024, Mark Wielaard wrote:
[...]
> But the part that interests me most is the self-registration part that
> Sergio setup. I believe we will need that for whatever system we end
> up with to make it as easy to contribute as it is with email.
> https://blog.sergio
Thanks for the bug report.
I am able to reproduce the problem. There are two things to consider
here:
1) ifupdown is not part of the default desktop image and as such it
needs to be installed anyway.
2) However, even after installing ifupdown, scripts under
/etc/network/if-up.d/ don't get
, 2024-04-30]
(https://discourse.ubuntu.com/t/27673)
Nothing to do.
--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14
signature.asc
Description: PGP signature
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu
Sorry, forgot to comment something else.
In the "Test Plan" section of the SRU text, could you please expand it a
bit and also include an actual execution of the udev rule in question in
order to confirm that the systemd-udev error doesn't happen anymore? It
is generally not enough to just check
Thank you for the patches.
I uploaded the Focal changes after verifying that the bug is indeed
present there. Bionic is in ESM now so I decided not to touch it; IIRC
the changes will need to go through another process in this case.
--
You received this bug notification because you are a member
** Changed in: openldap (Ubuntu)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/2064434
Title:
Me
** Changed in: rsync (Ubuntu)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/2064457
Title:
Merge rsync f
** Changed in: libvirt (Ubuntu)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064422
Title:
Merge libvirt from Debian unsta
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064450
Title:
Merge qemu from Debian unsta
** Changed in: sssd (Ubuntu)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064469
Title:
Merge sssd from Debian unsta
** Changed in: openldap (Ubuntu)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064434
Title:
Merge openldap from Debian unsta
** Changed in: rsync (Ubuntu)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064457
Title:
Merge rsync from Debian unsta
Andreas and I spent some time this afternoon investigating this issue.
Here are our findings.
First, we noticed that the paths being reported by apparmor on dmesg
appear to be relative to /run. This is just an impression, though: I
believe that, for some reason, apparmor/systemd/something-else
Andreas and I spent some time this afternoon investigating this issue.
Here are our findings.
First, we noticed that the paths being reported by apparmor on dmesg
appear to be relative to /run. This is just an impression, though: I
believe that, for some reason, apparmor/systemd/something-else
e usage:
> >
> > rtpengine.conf
> >
> > ### for userspace forwarding only:
> > table = -1
> >
> >
> > Mit freundlichen Grüssen
> >
> > -Benoît Panizzon-
>
> Hi @Benoit Panizzon and @Sergio Charrua,
> i set up rtpengine
https://github.com/skatrak approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/90090
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/90087
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -87,6 +88,27 @@ mlir::Type getLoopVarType(Fortran::lower::AbstractConverter
,
return converter.getFirOpBuilder().getIntegerType(loopVarTypeSize);
}
+Fortran::semantics::Symbol *
+getIterationVariableSymbol(const Fortran::lower::pft::Evaluation ) {
https://github.com/skatrak approved this pull request.
Thank you, LGTM. Just a small comment.
https://github.com/llvm/llvm-project/pull/90087
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
-
Sergio Durigan Junior (via nm.debian.org)
For details and to comment, visit https://nm.debian.org/process/1283/
--
https://nm.debian.org/process/1283/
ect
bsdextrautils
libsmartcols1
libblkid1
libmount1
mount
libuuid1
util-linux
libfdisk1
the problem went away.
Probably some version dependency should be added.
thanks
--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net
The odd thing is that the source code doesn't seem to have the original
patch...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1988440
Title:
Regression in 22.04: segmentation fault when language
Hmmm... the bugs are in the test_xmlb.c file, not in the library! These
variables are defined as autofree/autoptr
g_autofree gchar *blobfn = NULL;
g_autoptr(GPtrArray) parent_appdata = g_ptr_array_new_with_free_func
(g_free);
g_autoptr(GPtrArray) parent_appstream =
Created a PPA with a patched .deb for Jammy
https://launchpad.net/~rastersoft-gmail/+archive/ubuntu/libxmlb
Also, uploading the patch itself for Jammy.
** Patch added: "Patch for jammy libxmlb"
Confirmed: Jammy .deb package doesn't have the patch. I'll prepare a
SRU.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1988440
Title:
Regression in 22.04: segmentation fault when language is
https://bugs.kde.org/show_bug.cgi?id=434038
--- Comment #11 from Sergio ---
Let's see if this helps testing and as a consequence the consolidation of the
development of Maliit. Currently there are many issues, that I would like to
summarize as follows:
1. Maliit looks like a keyboard
if the software prints the **string colors** AFTER **scalar and identifier_1**
color, these colors are ovewritten by string color, and that seems to be the
deep problem.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3860#issuecomment-2081494130
Have done that, opened via Tools, replaced all the file content with the
configs you suggested and still not working.
I closed geany, reopened, and even think that **bash** is taken by geany as
**sh** too ?
--
Reply to this email directly or view it on GitHub:
One question: what is the correct: altering via Geany Tools, ... or editing
directly in the file /usr/share/geany/file...
Because opening in Tools, **all lines appear commented** and is is different
from the same file in /usr/share/geany/file...
What is actually used ?
--
Reply to this email
The bad news is that it doesn't work too.
I have added it, closed geany, reopen and all is the same.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3860#issuecomment-2081480908
You are receiving this because you are subscribed to this thread.
Message
PHP uses "preprocessor" color for the dollar variables, not identifier_1 ( that
sh/bash uses )
**The question is:** Why geany can draw php dollar variables interpolated in
string correctly, but not for shellscript ?
--
Reply to this email directly or view it on GitHub:
An important observation:
For single quoted string 'Single quoted string kills $dollar $vars' it is OK as
they kill dollar variables. In this case, the string color is used.
But double quotes "Double quotation keeps the $dollar $variables" they should
be colored as identifier_1 as geany does
I thank the lexer.bash.styling.inside.string information. How to set it ?
If Geany color application followed a simple rule, it would NOT depend on
language neither of this config.
The algorithm now paits string after the identifier_1 color with is for dollar
variables.
If just the identifier_1
I use vim and it always color the identifier with a different color. It
does not matter if is shell script or php.
If geany draws identifier_1 nicely out of the string and do not when the
dollar variable is interpolated in a string it is geany weakness and I
could myself show how to fix it
Em
An identifier inside a string should be colored as identifier, not as string.
Probably it's related to the execution order applying the colors.
Now the string scheme has more importance than identifier, and it should be
the opposite.
An example:
`"Here is a $variable is inside a string"`
For imlib2, rather add a fallback version of librsvg which does not need Rust
to be used on ppc (and wherever else needed).
We use that on macOS for ppc and old x86, it works fine.
Serge
On Apr 28, 2024 at 00:53 +0800, George Koehler , wrote:
> On Fri, 26 Apr 2024 07:15:51 +0800
> Serg
-04/>
As for question #2, certainly most of those 700Mb are related to outdated
packages that need some updates.
*Sérgio Charrua*
On Fri, Apr 26, 2024 at 5:42 PM christian.marinelli--- via sr-users <
sr-users@lists.kamailio.org> wrote:
> Sergio Charrua wrote:
> > The best solutio
@tjaalton Yes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1988440
Title:
Regression in 22.04: segmentation fault when language is spanish
To manage notifications about this bug go to:
(I mean: I'll do it :-D )
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1988440
Title:
Regression in 22.04: segmentation fault when language is spanish
To manage notifications about this bug go
Media |
Nick vs Networking
<https://nickvsnetworking.com/kamailio-bytes-rtp-media-proxying-with-rtpengine/>
*Sérgio Charrua*
On Fri, Apr 26, 2024 at 11:48 AM christian.marinelli--- via sr-users <
sr-users@lists.kamailio.org> wrote:
> christian.marinelli＠hotmail.it wrote:
>
Hi, could someone assist with fixing this?
We have XFCE unnecessarily broken due to dependency on GJS being forced. It is
in fact optional and not required for Glade.
It can be moved to a variant, and that variant made default for archs where GJS
builds.
Serge
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/89214
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/89211
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89214
>From 25dc3a45645ab2310606b2ab02346eed700c7f97 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 11:07:10 +0100
Subject: [PATCH] [MLIR][OpenMP] Update omp.wsloop translation to LLVM IR (
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89212
>From fdee8cf17cd7d2dbdb6cf872574776f02e70be7c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 10:55:16 +0100
Subject: [PATCH 1/2] [MLIR][SCF] Update scf.parallel lowering to OpenMP (
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89211
>From f9b14e37a6f437768c405291c064f541f0655b1c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Wed, 17 Apr 2024 16:40:03 +0100
Subject: [PATCH 1/2] [MLIR][OpenMP] Update op verifiers dependent on
omp.wsl
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89214
>From 25dc3a45645ab2310606b2ab02346eed700c7f97 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 11:07:10 +0100
Subject: [PATCH] [MLIR][OpenMP] Update omp.wsloop translation to LLVM IR (
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89212
>From fdee8cf17cd7d2dbdb6cf872574776f02e70be7c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 10:55:16 +0100
Subject: [PATCH 1/2] [MLIR][SCF] Update scf.parallel lowering to OpenMP (
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89211
>From f9b14e37a6f437768c405291c064f541f0655b1c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Wed, 17 Apr 2024 16:40:03 +0100
Subject: [PATCH 1/2] [MLIR][OpenMP] Update op verifiers dependent on
omp.wsl
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82852
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
This does appear to fix the issue for me on 23.10
```
sudo add-apt-repository ppa:vanvugt/mutter
sudo apt update
sudo apt upgrade
sudo shutdown -R now
```
Thanks a lot for this fix!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
This does appear to fix the issue for me on 23.10
```
sudo add-apt-repository ppa:vanvugt/mutter
sudo apt update
sudo apt upgrade
sudo shutdown -R now
```
Thanks a lot for this fix!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This does appear to fix the issue for me on 23.10
```
sudo add-apt-repository ppa:vanvugt/mutter
sudo apt update
sudo apt upgrade
sudo shutdown -R now
```
Thanks a lot for this fix!
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
Benoit is right!
Your issue is a common NAT issue: your SIP signalling is sending public IP
address on headers, while the SDP content is publishing internal/private IP
addresses:
[image: image.png]
Possible solutions:
1 - Use RTPEngine and integrate it with Kamailio
2 - let your Kamailio
Hello Brian, I don't see a relation with snapd in the error, it seems to
be unrelated. Is it possible to re-execute the tests please?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2058277
Title:
@@ -1977,9 +1977,10 @@ LogicalResult OrderedRegionOp::verify() {
if (getSimd())
return failure();
- if (auto container = (*this)->getParentOfType()) {
-if (!container.getOrderedValAttr() ||
-container.getOrderedValAttr().getInt() != 0)
+ if (auto loopOp =
@@ -33,6 +33,8 @@
#include "llvm/Transforms/Utils/ModuleUtils.h"
#include
+#include
+#include
skatrak wrote:
Maybe not needed if `std::iota` call is removed?
https://github.com/llvm/llvm-project/pull/82852
___
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2306,18 +2405,81 @@ static void processMapMembersWithParent(
llvm::OpenMPIRBuilder::DeviceInfoTy::None);
combinedInfo.Names.emplace_back(
LLVM::createMappingInformation(memberClause.getLoc(), ompBuilder));
-
-
@@ -2306,18 +2405,81 @@ static void processMapMembersWithParent(
llvm::OpenMPIRBuilder::DeviceInfoTy::None);
combinedInfo.Names.emplace_back(
LLVM::createMappingInformation(memberClause.getLoc(), ompBuilder));
-
-
@@ -2283,16 +2386,12 @@ static void processMapMembersWithParent(
for (auto mappedMembers : parentClause.getMembers()) {
auto memberClause =
mlir::dyn_cast(mappedMembers.getDefiningOp());
-int memberDataIdx = -1;
-for (size_t i = 0; i <
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2306,18 +2405,81 @@ static void processMapMembersWithParent(
llvm::OpenMPIRBuilder::DeviceInfoTy::None);
combinedInfo.Names.emplace_back(
LLVM::createMappingInformation(memberClause.getLoc(), ompBuilder));
-
-
@@ -2186,6 +2261,9 @@ calculateBoundsOffset(LLVM::ModuleTranslation
,
// which is utilised in subsequent member mappings (by modifying there map type
// with it) to indicate that a member is part of this parent and should be
// treated by the runtime as such. Important to
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82852
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak commented:
Thank you Andrew, as usual I have a lot of nits but the overall approach seems
reasonable to me.
https://github.com/llvm/llvm-project/pull/82852
___
llvm-branch-commits mailing list
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
In addition, since /var/lib/rasdaemon is no longer in the package's file list
it may need to be explicitly removed by the postrm script.
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
@@ -0,0 +1,260 @@
+//===- OMPMapInfoFinalization.cpp
+//---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -19,7 +19,7 @@
subroutine foo()
implicit none
-
+
skatrak wrote:
Nit: Accidental change?
https://github.com/llvm/llvm-project/pull/82853
___
llvm-branch-commits mailing list
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -966,6 +966,7 @@ genBodyOfTargetOp(Fortran::lower::AbstractConverter
,
mlir::Value mapOp = createMapInfoOp(
firOpBuilder, copyVal.getLoc(), copyVal, mlir::Value{}, name.str(),
bounds, llvm::SmallVector{},
+
@@ -0,0 +1,260 @@
+//===- OMPMapInfoFinalization.cpp
+//---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -218,17 +223,34 @@ bool ClauseProcessor::processMotionClauses(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp =
@@ -115,8 +115,7 @@ class ClauseProcessor {
bool processMap(
mlir::Location currentLocation, Fortran::lower::StatementContext
,
mlir::omp::MapClauseOps ,
- llvm::SmallVectorImpl *mapSyms =
- nullptr,
+ llvm::SmallVectorImpl *mapSyms,
@@ -1664,7 +1667,7 @@ genTargetOp(Fortran::lower::AbstractConverter ,
mlir::Value mapOp = createMapInfoOp(
firOpBuilder, baseOp.getLoc(), baseOp, mlir::Value{}, name.str(),
-bounds, {},
+bounds, {}, mlir::DenseIntElementsAttr{},
@@ -811,9 +811,10 @@ mlir::omp::MapInfoOp
createMapInfoOp(fir::FirOpBuilder , mlir::Location loc,
skatrak wrote:
It looks like this function belongs in Utils.cpp, rather than here. I suppose
that change doesn't belong in this PR, but it's something to keep in
@@ -185,7 +184,12 @@ template
bool ClauseProcessor::processMotionClauses(
skatrak wrote:
Not for this patch, but perhaps we should think about refactoring `processMap`
and `processMotionClauses` to avoid code duplication for those parts that are
shared
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
@@ -1177,10 +1178,11 @@ static void genTargetDataClauses(
llvm::SmallVectorImpl ,
llvm::SmallVectorImpl ,
llvm::SmallVectorImpl ) {
+ llvm::SmallVector mapSyms;
skatrak wrote:
Changes to this function can probably be reverted if `mapSyms` is made
@@ -218,17 +223,34 @@ bool ClauseProcessor::processMotionClauses(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp =
https://github.com/skatrak commented:
Thank you for all the work here Andrew, I've got some comments but they should
be relatively easy to address.
https://github.com/llvm/llvm-project/pull/82853
___
llvm-branch-commits mailing list
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82853
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/89104
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
1 - 100 of 66493 matches
Mail list logo
